deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-f3h7-gpjj-wcvh
Package: spin-sdk (RUST)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-610: Externally Controlled Reference to a Resource in Another Sphere
Vulnerable versions: < 2.4.3
Patched in: 2.4.3

Summary: Spin applications with specific configuration vulnerable to potential network sandbox escape

Details:
### Impact
Some specifically configured Spin applications that use `self` requests without a specified URL authority can be induced to make requests to arbitrary hosts via the `Host` HTTP header.

If an application's manifest contains a component with configuration such as
```toml
allowed_outbound_hosts = ["http://self", "https://self"]
```

and code such as
```rust
 let res: Response = spin_sdk::http::send(
        Request::new(Method::Get, "/") // Note: the request URI does not contain a URL authority
 ).await?;
```

Then that application can be induced to send an outgoing request to another host (leading the app to process the response assuming it comes from another component in the same application). This can be induced with a request such as
```shell
curl -H"Host: google.com:80" localhost:3000 # Assuming the application is served on localhost:3000
```

> Note: If using a SDK that does not use `wasi:http/outgoing-handler`, the port can be omitted from the URL.

#### Vulnerable Configurations

The following conditions need to be met for an application to be vulnerable:
1. The environment Spin is deployed in routes requests to the Spin runtime based on the request URL instead of the `Host` header, and leaves the `Host` header set to the original value by the client.
2. The Spin application's component handling the incoming request is configured with an `allowed_outbound_hosts` list containing `"self"`.
3. In reaction to an incoming request, the component makes an outbound request whose URL doesn't include the hostname/port.

If all of these conditions apply, then Spin will use the inbound request's `Host` header to determine the `authority` part of the URL if none is explicitly provided in the request's URL.

#### Setups known not to be vulnerable

Fermyon's [Fermyon Cloud](https://developer.fermyon.com/cloud/index) serverless product and applications hosted on it are known not to be vulnerable.


### Patches
_Has the problem been patched? What versions should users upgrade to?_
Spin version 2.4.3 is being released with this advisory going public.

### Workarounds
For deployments of Spin, a workaround is to ensure that the `Host` header is sanitized to match the application a request is routed to.

For individual applications, multiple workarounds exist:
1. Ensure that outgoing requests always sanitize the `Host` header
2. Ensure that outgoing requests always provide the hostname in the URL and use that hostname in the `allowed_outbound_hosts` list instead of `self`
3. When using Spin 2.4, use [application-internal service chaining](https://developer.fermyon.com/spin/v2/http-outbound#local-service-chaining) for intra-application requests
GitHub Security Advisory: GHSA-23rx-c3g5-hv9w
Package: deno (RUST)
Severity: HIGH (CVSS 8.4)
CWE: CWE-863: Incorrect Authorization
Vulnerable versions: < 1.43.1
Patched in: 1.43.1

Summary: Deno permission escalation vulnerability via open of privileged files with missing `--deny` flag

Details:
The Deno sandbox may be unexpectedly weakened by allowing file read/write access to privileged files in various locations on Unix and Windows platforms. For example, reading `/proc/self/environ` may provide access equivalent to `--allow-env`, and writing `/proc/self/mem` may provide access equivalent to `--allow-all`.

Users who grant read and write access to the entire filesystem may not realize that these access to these files may have additional, unintended consequences. The documentation did not reflect that this practice should be undertaken to increase the strength of the security sandbox. 

### Impact

Users who run code with `--allow-read` or `--allow-write` may unexpectedly end up granting additional permissions via file-system operations.

### Patches

Deno 1.43 and above require explicit `--allow-all` access to read or write `/etc`, `/dev` on unix platform (as well as `/proc` and `/sys` on linux platforms), and any path starting with `\\` on Windows.

### Workarounds

The security sandbox in previous versions of Deno allows for denial of access to these files, but it requires an explicit addition of deny flags: `--deny-read=/dev --deny-read=/sys --deny-read=/proc --deny-read=/etc --deny-write=/dev --deny-write=/sys --deny-write=/proc --deny-write=/etc`. Note that symlinks in allowed locations may defeat this protection in earlier versions of Deno.

### Reporters

This vulnerability was reported by a number of analysts. Thanks to [oliver@secfault-security.com](mailto:oliver@secfault-security.com), [finn@secfault-security.com](mailto:finn@secfault-security.com), @leesh3288, and @cristianstaicu for their reports and analysis.
GitHub Security Advisory: GHSA-c3hm-hxwf-g5c6
Package: vodozemac (RUST)
Severity: LOW (CVSS 2.5)
CWE: CWE-1188: Initialization of a Resource with an Insecure Default
Vulnerable versions: >= 0.5.0, < 0.6.0
Patched in: 0.6.0

Summary: vodozemac has degraded secret zeroization capabilities

Details:
Versions 0.5.0 and 0.5.1 of vodozemac have degraded secret zeroization capabilities, due to changes in third-party cryptographic dependencies (the Dalek crates), which moved secret zeroization capabilities behind a feature flag while vodozemac disabled the default feature set.

### Impact
The degraded zeroization capabilities could result in the production of more memory copies of encryption secrets and secrets could linger in memory longer than necessary. This marginally increases the risk of sensitive data exposure.

Overall, we consider the impact of this issue to be low. Although cryptographic best practices recommend the clearing of sensitive information from memory once it's no longer needed, the inherent limitations of Rust regarding absolute zeroization reduce the practical severity of this lapse.

### Patches
The patch is in commit https://github.com/matrix-org/vodozemac/pull/130/commits/297548cad4016ce448c4b5007c54db7ee39489d9.

### Workarounds
None.

### For more information
If you have any questions or comments about this advisory please email us at [security at matrix.org](mailto:security@matrix.org).
GitHub Security Advisory: GHSA-3999-5ffv-wp2r
Package: yamux (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-400: Uncontrolled Resource Consumption
Vulnerable versions: >= 0.13.0, < 0.13.2
Patched in: 0.13.2

Summary: Yamux Memory Exhaustion Vulnerability via Active::pending_frames property 

Details:
### Summary

Attack scenario
The Rust implementation of the Yamux stream multiplexer uses a vector for pending frames. This vector is not bounded in length. Every time the Yamux protocol requires sending of a new frame, this frame gets appended to this vector. This can be remotely triggered in a number of ways, for example by:

1. Opening a new libp2p Identify stream. This causes the node to send its Identify message. Of course, every other protocol that causes the sending of data also works. The larger the response, the more data is enqueued.
2. Sending a Yamux Ping frame. This causes a Pong frame to be enqueued.

Under normal circumstances, this queue of pending frames would be drained once they’re sent out over the network. However, the attacker can use TCP’s receive window mechanism to prevent the victim from sending out any data: By not reading from the TCP connection, the receive window will never be increased, and the victim won’t be able to send out any new data (this is how TCP implements backpressure). Once this happens, Yamux’s queue of pending frames will start growing indefinitely. The queue will only be drained once the underlying TCP connection is closed.

Components
https://github.com/libp2p/rust-yamux/blob/yamux-v0.13.1/yamux/src/connection.rs#L289

### Details
This attack is inspired by the HTTP/2 Rapid Reset Attack (CVE 2023-44487), HTTP/2 Ping Flood (CVE-2019-9512), and the QUIC Path Validation attack (see my blog post: https://seemann.io/posts/2023-12-18-exploiting-quics-path-validation/).

### Impact
An attacker can cause a remote node to run out of memory, which will result in the corresponding process getting terminated by the operating system.

Depending on the application protocols running on top of rust-libp2p, higher amplification factors are possible. For example, image a protocol that sends out 10 MB of data as a result of an incoming request. By issuing that request and sending a Yamux stream window update (together ~100-200 bytes), the victim would now enqueue the entire 10 MB into its frame buffer. Any block transfer / sync protocols might be good candidates.

In addition to consuming huge amounts of memory, this attack also drives up the victim's CPU load, such that the allocation of memory at some point becomes CPU-limited.

This was originally submitted by @marteen-seemann to the Ethereum Foundation bug bounty program.
GitHub Security Advisory: GHSA-rwfq-v4hq-h7fg
Package: static-web-server (RUST)
Severity: MODERATE (CVSS 5.8)
CWE: CWE-79: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting'), CWE-80: Improper Neutralization of Script-Related HTML Tags in a Web Page (Basic XSS)
Vulnerable versions: < 2.30.0
Patched in: 2.30.0

Summary: static-web-server vulnerable to stored Cross-site Scripting in directory listings via file names

Details:
### Summary
If directory listings are enabled for a directory that an untrusted user has upload privileges for, a malicious file name like `<img src=x onerror=alert(1)>.txt` will allow JavaScript code execution in the context of the web server’s domain.

### Details
SWS generally does not perform escaping of HTML entities on any values inserted in the directory listing. At the very least `file_name` and `current_path` could contain malicious data however. `file_uri` could also be malicious but the relevant scenarios seem to be all caught by hyper.

### Impact
For any web server that allow users to upload files or create directories under a name of their choosing this becomes a stored XSS vulnerability.
GitHub Security Advisory: GHSA-8724-5xmm-w5xq
Package: cosmwasm-std (RUST)
Severity: LOW (CVSS 3.7)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: >= 2.0.0, < 2.0.2
Patched in: 2.0.2

Summary: CosmWasm affected by arithmetic overflows

Details:
Some mathematical operations in `cosmwasm-std` use wrapping math instead of panicking on overflow for very big numbers. This can lead to wrong calculations in contracts that use these operations.

Affected functions:

- `Uint{256,512}::pow` / `Int{256,512}::pow`
- `Int{256,512}::neg`

Affected if `overflow-checks = true` is not set:

- `Uint{64,128}::pow` / `Int{64,128}::pow`
- `Int{64,128}::neg`
GitHub Security Advisory: GHSA-8724-5xmm-w5xq
Package: cosmwasm-std (RUST)
Severity: LOW (CVSS 3.7)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: >= 1.5.0, < 1.5.4
Patched in: 1.5.4

Summary: CosmWasm affected by arithmetic overflows

Details:
Some mathematical operations in `cosmwasm-std` use wrapping math instead of panicking on overflow for very big numbers. This can lead to wrong calculations in contracts that use these operations.

Affected functions:

- `Uint{256,512}::pow` / `Int{256,512}::pow`
- `Int{256,512}::neg`

Affected if `overflow-checks = true` is not set:

- `Uint{64,128}::pow` / `Int{64,128}::pow`
- `Int{64,128}::neg`
GitHub Security Advisory: GHSA-8724-5xmm-w5xq
Package: cosmwasm-std (RUST)
Severity: LOW (CVSS 3.7)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: >= 1.3.0, < 1.4.4
Patched in: 1.4.4

Summary: CosmWasm affected by arithmetic overflows

Details:
Some mathematical operations in `cosmwasm-std` use wrapping math instead of panicking on overflow for very big numbers. This can lead to wrong calculations in contracts that use these operations.

Affected functions:

- `Uint{256,512}::pow` / `Int{256,512}::pow`
- `Int{256,512}::neg`

Affected if `overflow-checks = true` is not set:

- `Uint{64,128}::pow` / `Int{64,128}::pow`
- `Int{64,128}::neg`
GitHub Security Advisory: GHSA-mc39-h54g-pvw6
Package: libdav1d-sys (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-190: Integer Overflow or Wraparound
Vulnerable versions: < 0.7.0
Patched in: 0.7.0

Summary: libdav1d-sys affected by dav1d AV1 decoder integer overflow

Details:
An integer overflow in dav1d AV1 decoder that can occur when decoding videos with large frame size. This can lead to memory corruption within the AV1 decoder. We recommend upgrading to version 0.7.0 of libdav1d-sys, which includes dav1d 1.4.0.
GitHub Security Advisory: GHSA-5gmm-6m36-r7jh
Package: transpose (RUST)
Severity: MODERATE (CVSS 4.5)
CWE: CWE-120: Buffer Copy without Checking Size of Input ('Classic Buffer Overflow'), CWE-190: Integer Overflow or Wraparound
Vulnerable versions: >= 0.1.0, < 0.2.3
Patched in: 0.2.3

Summary: transpose: Buffer overflow due to integer overflow

Details:
Given the function `transpose::transpose`:
```rust
fn transpose<T: Copy>(input: &[T], output: &mut [T], input_width: usize, input_height: usize)
```

The safety check `input_width * input_height == output.len()` can fail due to `input_width * input_height` overflowing in such a way that it equals `output.len()`.
As a result of failing the safety check, memory past the end of `output` is written to. This only occurs in release mode since `*` panics on overflow in debug mode.

Exploiting this issue requires the caller to pass `input_width` and `input_height` arguments such that multiplying them overflows, and the overflown result equals the lengths of input and output slices.
GitHub Security Advisory: GHSA-xfhw-6mc4-mgxf
Package: crayon (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-908: Use of Uninitialized Resource
Vulnerable versions: >= 0.6.0, <= 0.7.1
Patched in: unpatched

Summary: crayon: ObjectPool creates uninitialized memory when freeing objects

Details:
As of version 0.6.0, the ObjectPool explicitly creates an uninitialized instance of its type parameter when it attempts to free an object, and swaps it into the storage. This causes instant undefined behavior due to reading the uninitialized memory in order to write it to the pool storage.

Extremely basic usage of the crate can trigger this issue, e.g. this code from a doctest:

```rust
use crayon::prelude::*;
application::oneshot().unwrap();

let mut params = MeshParams::default();

let mesh = video::create_mesh(params, None).unwrap();

// Deletes the mesh object.
video::delete_mesh(mesh); // <-- UB
```

The Clippy warning for this code was silenced in commit c2fde19caf6149d91faa504263f0bc5cafc35de5.

Discovered via https://asan.saethlin.dev/ub?crate=crayon&version=0.7.1
GitHub Security Advisory: GHSA-w5w5-8vfh-xcjq
Package: whoami (RUST)
Severity: HIGH (CVSS 8.2)
CWE: CWE-121: Stack-based Buffer Overflow
Vulnerable versions: >= 0.5.3, < 1.5.0
Patched in: 1.5.0

Summary: whoami stack buffer overflow on several Unix platforms

Details:
With versions of the whoami crate >= 0.5.3 and < 1.5.0, calling any of these functions leads to an immediate stack buffer overflow on illumos and Solaris:

- `whoami::username`
- `whoami::realname`
- `whoami::username_os`
- `whoami::realname_os`

With versions of the whoami crate >= 0.5.3 and < 1.0.1, calling any of the above functions also leads to a stack buffer overflow on these platforms:

- Bitrig
- DragonFlyBSD
- FreeBSD
- NetBSD
- OpenBSD

This occurs because of an incorrect definition of the `passwd` struct on those platforms.

As a result of this issue, denial of service and data corruption have both been observed in the wild. The issue is possibly exploitable as well.

This vulnerability also affects other Unix platforms that aren't Linux or macOS.

This issue has been addressed in whoami 1.5.0.

For more information, see [this GitHub issue](https://github.com/ardaku/whoami/issues/91).
GitHub Security Advisory: GHSA-4v52-7q2x-v4xj
Package: eyre (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: >= 0.6.9, < 0.6.12
Patched in: 0.6.12

Summary: eyre: Parts of Report are dropped as the wrong type during downcast

Details:
In affected versions, after a `Report` is constructed using `wrap_err` or `wrap_err_with` to attach a message of type `D` onto an error of type `E`, then using `downcast` to recover ownership of either the value of type `D` or the value of type `E`, one of two things can go wrong:

- If downcasting to `E`, there remains a value of type `D` to be dropped. It is incorrectly "dropped" by running `E`'s drop behavior, rather than `D`'s. For example if `D` is `&str` and `E` is `std::io::Error`, there would be a call of `std::io::Error::drop` in which the reference received by the `Drop` impl does not refer to a valid value of type `std::io::Error`, but instead to `&str`.

- If downcasting to `D`, there remains a value of type `E` to be dropped. When `D` and `E` do not happen to be the same size, `E`'s drop behavior is incorrectly executed in the wrong location. The reference received by the `Drop` impl may point left or right of the real `E` value that is meant to be getting dropped.

In both cases, when the `Report` contains an error `E` that has nontrivial drop behavior, the most likely outcome is memory corruption.

When the `Report` contains an error `E` that has trivial drop behavior (for example a `Utf8Error`) but where `D` has nontrivial drop behavior (such as `String`), the most likely outcome is that downcasting to `E` would leak `D`.
GitHub Security Advisory: GHSA-w7hm-hmxv-pvhf
Package: hpack (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: <= 0.3.0
Patched in: unpatched

Summary: HPACK decoder panics on invalid input

Details:
Due to insufficient checking of input data, decoding certain data sequences can lead to _Decoder::decode_ panicking rather than returning an error.

Example code that triggers this vulnerability looks like this:

```rust
use hpack::Decoder;

pub fn main() {
  let input = &[0x3f];
  let mut decoder = Decoder::new();
  let _ = decoder.decode(input);
}
```

hpack is unmaintained. A crate with the panics fixed has been published as [hpack-patched](https://crates.io/crates/hpack-patched).

Also consider using [fluke-hpack](https://crates.io/crates/fluke-hpack) or [httlib-huffman](https://crates.io/crates/httlib-huffman) as an alternative.
GitHub Security Advisory: GHSA-q6cp-qfwq-4gcv
Package: h2 (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: >= 0.4.0, < 0.4.4
Patched in: 0.4.4

Summary: h2 servers vulnerable to degradation of service with CONTINUATION Flood

Details:
An attacker can send a flood of CONTINUATION frames, causing `h2` to process them indefinitely. This results in an increase in CPU usage.

Tokio task budget helps prevent this from a complete denial-of-service, as the server can still respond to legitimate requests, albeit with increased latency.

More details at https://seanmonstar.com/blog/hyper-http2-continuation-flood/.

Patches available for 0.4.x and 0.3.x versions.
GitHub Security Advisory: GHSA-q6cp-qfwq-4gcv
Package: h2 (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-400: Uncontrolled Resource Consumption, CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 0.3.26
Patched in: 0.3.26

Summary: h2 servers vulnerable to degradation of service with CONTINUATION Flood

Details:
An attacker can send a flood of CONTINUATION frames, causing `h2` to process them indefinitely. This results in an increase in CPU usage.

Tokio task budget helps prevent this from a complete denial-of-service, as the server can still respond to legitimate requests, albeit with increased latency.

More details at https://seanmonstar.com/blog/hyper-http2-continuation-flood/.

Patches available for 0.4.x and 0.3.x versions.
GitHub Security Advisory: GHSA-x9xc-63hg-vcfq
Package: cassandra-cpp (RUST)
Severity: HIGH (CVSS 7.5)
CWE: CWE-416: Use After Free
Vulnerable versions: < 3.0.0
Patched in: 3.0.0

Summary: cassandra-rs's non-idiomatic use of iterators leads to use after free

Details:
### Impact
Code that attempts to use an item (e.g., a row) returned by an iterator after the iterator has advanced to the next item will be accessing freed memory and experience undefined behaviour. Code that uses the item and then advances the iterator is unaffected. This problem has always existed.

This is a use-after-free bug, so it's rated high severity. If your code uses a pre-3.0.0 version of cassandra-rs, and uses an item returned by a cassandra-rs iterator after calling `next()` on that iterator, then it is vulnerable. However, such code will almost always fail immediately - so we believe it is unlikely that any code using this pattern would have reached production. For peace of mind, we recommend you upgrade anyway.

### Patches
The problem has been fixed in version 3.0.0. Users should upgrade to ensure their code cannot use the problematic pattern.

### Workarounds
Ensure all usage fits the expected pattern. For example, use `get_first_row()` rather than an iterator, or completely process an item before advancing the iterator with `next()`.

### References
None.
GitHub Security Advisory: GHSA-75hq-h6g9-h4q5
Package: wasmtime (RUST)
Severity: LOW (CVSS 3.3)
CWE: CWE-843: Access of Resource Using Incompatible Type ('Type Confusion')
Vulnerable versions: = 19.0.0
Patched in: 19.0.1

Summary: Wasmtime vulnerable to panic when using a dropped extenref-typed element segment

Details:
### Impact

The 19.0.0 release of Wasmtime contains a regression introduced during its development which can lead to a guest WebAssembly module causing a panic in the host runtime. A valid WebAssembly module, when executed at runtime, may cause this panic. The panic in question is caused when a WebAssembly module issues a `table.*` instruction which uses a dropped element segment with a table that also has an `externref` type. This causes Wasmtime to erroneously use an empty function segment instead of an empty externref segment to perform this operation. This mismatch in types causes a panic in Wasmtime when it's asserted that an externref table is only viewed as externrefs.

This regression was introduced during the development of the 19.0.0 release and only affects the 19.0.0 release. This panic requires the `reference-types` WebAssembly feature to be enabled, and it is enabled by default. Toolchains are not known to generate this pattern by default so it's likely a module would need to be specifically crafted to trigger this panic.

A panic in a host runtime represents a possible denial-of-service in some scenarios. This panic cannot introduce memory unsafety or allow WebAssembly to break outside of its sandbox, however. There is no possible heap corruption or memory unsafety from this panic.

### Patches

Wasmtime 19.0.1 has been released to fix this problem. Users of 19.0.0 should upgrade to 19.0.1. All other versions of Wasmtime are not affected by this issue.

### Workarounds

If upgrading is not possible it's recommended to use `config.reference_types(false)`. That will disable these modules at validation-time which prevents the possibility of a panic at runtime. If reference-types are required, however, then there is no other workaround at this time other than upgrading.

### References

* [Original bug report](https://github.com/bytecodealliance/wasmtime/issues/8281)
* [PR to fix the bug](https://github.com/bytecodealliance/wasmtime/pull/8283)
* [PR that introduced the bug](https://github.com/bytecodealliance/wasmtime/pull/8018)