deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-fm79-3f68-h2fc
Package: wasmtime-wasi (RUST)
Severity: LOW (CVSS 3.5)
CWE: CWE-672: Operation on a Resource after Expiration or Release
Vulnerable versions: >= 25.0.0, < 33.0.2
Patched in: 33.0.2

Summary: Wasmtime CLI  is vulnerable to host panic through its fd_renumber function

Details:
### Summary

A bug in Wasmtime's implementation of the WASIp1 set of import functions can lead to a WebAssembly guest inducing a panic in the host (embedder).
The specific bug is triggered by calling `path_open` after calling `fd_renumber` with either:
- two equal argument values
- second argument being equal to a previously-closed file descriptor number value

The corrupt state introduced in `fd_renumber` will lead to the subsequent opening of a file descriptor to panic. 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.

This bug is in the implementation of Wasmtime's `wasmtime-wasi` crate which provides an implementation of WASIp1. The bug requires a specially crafted call to `fd_renumber` in addition to the ability to open a subsequent file descriptor. Opening a second file descriptor is only possible when a preopened directory was provided to the guest, and this is common amongst embeddings. A panic in the host is considered a denial-of-service vector for WebAssembly embedders and is thus a security issue in Wasmtime.

This bug does not affect WASIp2 and embedders using components.

### Patches

In accordance with Wasmtime's [release process](https://docs.wasmtime.dev/stability-release.html) patch releases are available as 24.0.4, 33.0.2, and 34.0.2. Users of other release of Wasmtime are recommended to move to a supported release of Wasmtime.

### Workarounds

Embedders who are using components or are not providing guest access to create more file descriptors (e.g. via a preopened filesystem directory) are not affected by this issue. Otherwise there is no workaround at this time and affected embeddings are recommended to update to a patched version which will not cause a panic in the host.
GitHub Security Advisory: GHSA-fm79-3f68-h2fc
Package: wasmtime-wasi (RUST)
Severity: LOW (CVSS 3.5)
CWE: CWE-672: Operation on a Resource after Expiration or Release
Vulnerable versions: < 24.0.4
Patched in: 24.0.4

Summary: Wasmtime CLI  is vulnerable to host panic through its fd_renumber function

Details:
### Summary

A bug in Wasmtime's implementation of the WASIp1 set of import functions can lead to a WebAssembly guest inducing a panic in the host (embedder).
The specific bug is triggered by calling `path_open` after calling `fd_renumber` with either:
- two equal argument values
- second argument being equal to a previously-closed file descriptor number value

The corrupt state introduced in `fd_renumber` will lead to the subsequent opening of a file descriptor to panic. 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.

This bug is in the implementation of Wasmtime's `wasmtime-wasi` crate which provides an implementation of WASIp1. The bug requires a specially crafted call to `fd_renumber` in addition to the ability to open a subsequent file descriptor. Opening a second file descriptor is only possible when a preopened directory was provided to the guest, and this is common amongst embeddings. A panic in the host is considered a denial-of-service vector for WebAssembly embedders and is thus a security issue in Wasmtime.

This bug does not affect WASIp2 and embedders using components.

### Patches

In accordance with Wasmtime's [release process](https://docs.wasmtime.dev/stability-release.html) patch releases are available as 24.0.4, 33.0.2, and 34.0.2. Users of other release of Wasmtime are recommended to move to a supported release of Wasmtime.

### Workarounds

Embedders who are using components or are not providing guest access to create more file descriptors (e.g. via a preopened filesystem directory) are not affected by this issue. Otherwise there is no workaround at this time and affected embeddings are recommended to update to a patched version which will not cause a panic in the host.
GitHub Security Advisory: GHSA-7mcq-f592-pf7v
Package: slice-ring-buffer (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-415: Double Free
Vulnerable versions: <= 0.3.4
Patched in: unpatched

Summary: Slice Ring Buffer and Slice Deque contains four unique double-free vulnerabilities triggered through safe APIs

Details:
The crate [`slice-ring-buffer`](https://crates.io/crates/slice-ring-buffer) was developed as a fork of [`slice-deque`](https://crates.io/crates/slice-deque) to continue maintenance and provide security patches, since the latter has been officially unmaintained ([RUSTSEC-2020-0158](https://rustsec.org/advisories/RUSTSEC-2020-0158.html)).

While `slice-ring-buffer` has addressed some previously reported memory safety issues inherited from its fork origin ([RUSTSEC-2021-0047](https://rustsec.org/advisories/RUSTSEC-2021-0047.html)), it still retains multiple unresolved memory corruption vulnerabilities.

Specifically, we have discovered four new memory safety bugs, each resulting in double-free violations that can occur when only safe APIs are invoked. These vulnerabilities correspond to four distinct safe APIs in the crate, each exposing unsound and vulnerable behavior due to incorrect usage of unsafe code internally.

Unfortunately, the maintainer doesn't have much availability to resolve these issues so there's no concrete timeline for fixes. Community contributions towards fixing these vulnerabilities would be much appreciated.
GitHub Security Advisory: GHSA-7mcq-f592-pf7v
Package: slice-deque (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-415: Double Free
Vulnerable versions: <= 0.3.0
Patched in: unpatched

Summary: Slice Ring Buffer and Slice Deque contains four unique double-free vulnerabilities triggered through safe APIs

Details:
The crate [`slice-ring-buffer`](https://crates.io/crates/slice-ring-buffer) was developed as a fork of [`slice-deque`](https://crates.io/crates/slice-deque) to continue maintenance and provide security patches, since the latter has been officially unmaintained ([RUSTSEC-2020-0158](https://rustsec.org/advisories/RUSTSEC-2020-0158.html)).

While `slice-ring-buffer` has addressed some previously reported memory safety issues inherited from its fork origin ([RUSTSEC-2021-0047](https://rustsec.org/advisories/RUSTSEC-2021-0047.html)), it still retains multiple unresolved memory corruption vulnerabilities.

Specifically, we have discovered four new memory safety bugs, each resulting in double-free violations that can occur when only safe APIs are invoked. These vulnerabilities correspond to four distinct safe APIs in the crate, each exposing unsound and vulnerable behavior due to incorrect usage of unsafe code internally.

Unfortunately, the maintainer doesn't have much availability to resolve these issues so there's no concrete timeline for fixes. Community contributions towards fixing these vulnerabilities would be much appreciated.
GitHub Security Advisory: GHSA-275g-g844-73jh
Package: matrix-sdk-sqlite (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 0.11.0, < 0.13.0
Patched in: 0.13.0

Summary: Matrix Rust SDK vulnerable to SQL Injection through its EventCache implementation

Details:
An SQL injection vulnerability in the `EventCache::find_event_with_relations` method of matrix-sdk 0.11 and 0.12 allows malicious room members to execute arbitrary SQL commands in Matrix clients that directly pass relation types provided by those room members into this method, when used with the default sqlite-based store backend. Exploitation is unlikely, as no known clients currently use the API in this manner.

### Workarounds

Passing only trusted (or sanitised) relation types to the `filter` argument of `EventCache::find_event_with_relations()` avoids the issue.

### Patches

The issue is fixed in matrix-sdk 0.13.

### References

The issue was introduced in https://github.com/matrix-org/matrix-rust-sdk/pull/4849.
GitHub Security Advisory: GHSA-275g-g844-73jh
Package: matrix-sdk (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-89: Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
Vulnerable versions: >= 0.11.0, < 0.13.0
Patched in: 0.13.0

Summary: Matrix Rust SDK vulnerable to SQL Injection through its EventCache implementation

Details:
An SQL injection vulnerability in the `EventCache::find_event_with_relations` method of matrix-sdk 0.11 and 0.12 allows malicious room members to execute arbitrary SQL commands in Matrix clients that directly pass relation types provided by those room members into this method, when used with the default sqlite-based store backend. Exploitation is unlikely, as no known clients currently use the API in this manner.

### Workarounds

Passing only trusted (or sanitised) relation types to the `filter` argument of `EventCache::find_event_with_relations()` avoids the issue.

### Patches

The issue is fixed in matrix-sdk 0.13.

### References

The issue was introduced in https://github.com/matrix-org/matrix-rust-sdk/pull/4849.
GitHub Security Advisory: GHSA-xrrq-rrgq-h89w
Package: static-alloc (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-908: Use of Uninitialized Resource
Vulnerable versions: >= 0.2.2, < 0.2.6
Patched in: 0.2.6

Summary: static-alloc vulnerability leads to uninitialized read after allocating MemBump

Details:
The affected function, `MemBump::new()`, would allocate memory without initializing it. Subsequently calling the created value's various `alloc`methods would then read and write the start of that memory as a `Cell` which isundefined behavior. Instead, it should zero initialize the start of the allocated memory.

For instance, some values could violate the internal invariants of the type and cause an assertion failure. Nevertheless, no deterministic read is known tocause further uninitialized memory to be exposed.

Affected downstream users that can not upgrade are advised to call `MemBump::reset` immediately after allocation to manually perform the missing write of the counter best-as-possible.

The flaw was corrected in commit d8d6a7d096d3aaafd963b356a8f1bbd8d26fd967 by zeroing the Cell at the start of the allocated memory.
GitHub Security Advisory: GHSA-rxf6-323f-44fc
Package: protobuf (RUST)
Severity: MODERATE (CVSS 5.9)
CWE: CWE-674: Uncontrolled Recursion
Vulnerable versions: < 3.7.2
Patched in: 3.7.2

Summary: Duplicate Advisory: rust-protobuf crate is vulnerable to Uncontrolled Recursion, potentially leading to DoS

Details:
### Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-2gh3-rmm4-6rq5. This link is maintained to preserve external references.

###
The protobuf crate before 3.7.2 for Rust allows uncontrolled recursion in the protobuf::coded_input_stream::CodedInputStream::skip_group parsing of unknown fields in untrusted input.
GitHub Security Advisory: GHSA-287x-9rff-qvcg
Package: web-push (RUST)
Severity: MODERATE (CVSS 4.0)
CWE: CWE-130: Improper Handling of Length Parameter Inconsistency
Vulnerable versions: <= 0.10.2
Patched in: 0.10.4

Summary: Rust Web Push is vulnerable to a DoS attack via a large integer in a Content-Length header

Details:
The web-push crate before 0.10.4 for Rust allows a denial of service (memory consumption) in the built-in clients via a large integer in a Content-Length header. The patch was initially made available in version 0.10.3, but version 0.10.3 has since been yanked.
GitHub Security Advisory: GHSA-3w94-vq2x-v5wr
Package: ethereum (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-754: Improper Check for Unusual or Exceptional Conditions
Vulnerable versions: < 0.18.0
Patched in: 0.18.0

Summary: ethereum does not check transaction malleability for EIP-2930, EIP-1559 and EIP-7702 transactions

Details:
### Impact

Prior to `ethereum` crate v0.18.0, signature malleability (according to EIP-2) was only checked for "legacy" transactions, but not for EIP-2930, EIP-1559 and EIP-7702 transactions.

This is a specification deviation and therefore a high severity advisory if the `ethereum` crate is used for Ethereum mainnet. Note that signature malleability itself is not a security issue, and therefore if the `ethereum` crate is used on a single-implementation blockchain, it's a low/informational severity advisory.

### Patches

The issue is fixed in `ethereum` v0.18.0

### Workarounds

You can also manually check transaction malleability outside of the crate. But it's recommended to simply upgrade the version.

### References

See PR: https://github.com/rust-ethereum/ethereum/pull/67
GitHub Security Advisory: GHSA-gjv3-89hh-9xq2
Package: risc0-ethereum-contracts (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-159: Improper Handling of Invalid Use of Special Elements
Vulnerable versions: < 2.1.1
Patched in: 2.1.1

Summary: RISC Zero Ethereum invalid commitment with digest value of zero accepted by Steel.validateCommitment

Details:
### Impact

Prior to 2.1.1 and 2.2.0, the `Steel.validateCommitment` Solidity library function will return `true` for a crafted commitment with a digest value of zero.

This violates the semantics of `validateCommitment`, as this does not commitment to a block that is in the current chain. Because the digest is zero, it does not correspond to any block and there exist no known openings. As a result, this commitment will never be produced by a correct zkVM guest using Steel. Leveraging this bug to compromise the soundness of an application using Steel would require a separate bug or misuse of the Steel library, which is expected to be used to validate the root of state opening proofs (e.g. having the guest commit to a digest of zero, or failing to check the zkVM proof).

Because this bug does not risk application integrity, correctly written applications are not at risk.

### Fix

Please see [#605] for a full description of the bug, and the fix. This fix has been released as part of `risc0-ethereum` [2.1.1] and [2.2.0].

### Recommended actions

Users for the `Steel` Solidity library versions 2.1.0 or earlier should ensure they are using `Steel.validateCommitment` in tandem with zkVM proof verification of a Steel program, as shown in the [ERC-20 counter example][example], and [documentation]. This is the correct usage of Steel, and users following this pattern are not at risk, and do not need to take action.

Users not verifying a zkVM proof of a Steel program should update their application to do so, as this is incorrect usage of Steel.

### Credit

A thank you to Daniel526 on HackenProof for reporting this issue

[#605]: https://github.com/risc0/risc0-ethereum/pull/605
[example]: https://github.com/risc0/risc0-ethereum/blob/ff0cb9253a87945b653b825711b8b5075f8b7545/examples/erc20-counter/contracts/src/Counter.sol#L56-L63
[documentation]: https://docs.beboundless.xyz/developers/steel/how-it-works#verifying-the-proof-onchain
[2.1.1]: https://github.com/risc0/risc0-ethereum/releases/tag/v2.1.1
[2.2.0]: https://github.com/risc0/risc0-ethereum/releases/tag/v2.2.0
GitHub Security Advisory: GHSA-jpv7-p47h-f43j
Package: letmeinfwd (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 10.2.0
Patched in: 10.2.1

Summary: letmein connection limiter allows an arbitrary amount of simultaneous connections

Details:
### Impact

The connection limiter is implemented incorrectly.
It allows an arbitrary amount of simultaneously incoming connections (TCP, UDP and Unix socket) for the services `letmeind` and `letmeinfwd`.
Therefore, the command line option `num-connections` is not effective and does not limit the number of simultaneously incoming connections.

`letmeind` is the public network facing daemon (TCP/UDP).

`letmeinfwd` is the internal firewall daemon that only listens on local Unix socket.

Possible Denial Of Service by resource exhaustion.

### Affected versions
All versions `<= 10.2.0` are affected.

### Patches
All users shall upgrade to version `10.2.1`.

### Workarounds

Untested possible workarounds:
- It might be possible to limit the number of active connections to the `letmeind` port (default 5800) via firewall.
- The resource consumption of the service might be restricted with a service manager such as systemd.

### Severity:

If a (D)DoS is run against the service, *something* is going to be affected.
The connection limiter assures that the effect on the system itself is limited at the expense of the effect on the letmein services itself.
So even with the connection limiter active, a (D)DoS can lead to a less responsive or unresponsive letmein service.
GitHub Security Advisory: GHSA-jpv7-p47h-f43j
Package: letmeind (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: <= 10.2.0
Patched in: 10.2.1

Summary: letmein connection limiter allows an arbitrary amount of simultaneous connections

Details:
### Impact

The connection limiter is implemented incorrectly.
It allows an arbitrary amount of simultaneously incoming connections (TCP, UDP and Unix socket) for the services `letmeind` and `letmeinfwd`.
Therefore, the command line option `num-connections` is not effective and does not limit the number of simultaneously incoming connections.

`letmeind` is the public network facing daemon (TCP/UDP).

`letmeinfwd` is the internal firewall daemon that only listens on local Unix socket.

Possible Denial Of Service by resource exhaustion.

### Affected versions
All versions `<= 10.2.0` are affected.

### Patches
All users shall upgrade to version `10.2.1`.

### Workarounds

Untested possible workarounds:
- It might be possible to limit the number of active connections to the `letmeind` port (default 5800) via firewall.
- The resource consumption of the service might be restricted with a service manager such as systemd.

### Severity:

If a (D)DoS is run against the service, *something* is going to be affected.
The connection limiter assures that the effect on the system itself is limited at the expense of the effect on the letmein services itself.
So even with the connection limiter active, a (D)DoS can lead to a less responsive or unresponsive letmein service.
GitHub Security Advisory: GHSA-5p2p-6g2c-hf7m
Package: spytrap-adb (RUST)
Severity: LOW (CVSS 2.7)
CWE: CWE-223: Omission of Security-relevant Information
Vulnerable versions: < 0.3.5
Patched in: 0.3.5

Summary: spytrap-adb Omission of Security-relevant Information

Details:
In scan.rs in spytrap-adb before 0.3.5, matches for known stalkerware are not rendered in the interactive user interface.
GitHub Security Advisory: GHSA-g3qg-6746-3mg9
Package: risc0-circuit-rv32im (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: >= 2.0.0, <= 2.0.3
Patched in: 2.0.4

Summary: zkVM Underconstrained Vulnerability

Details:
Due to a missing constraint in the rv32im circuit, any 3-register RISC-V instruction (including remu and divu) in risc0-zkvm 2.0.0, 2.0.1, and 2.0.2 are vulnerable to an attack by a malicious prover. The main idea for the attack is to confuse the RISC-V virtual machine into treating the value of the rs1 register as the same as the rs2 register due to a lack of constraints in the rv32im circuit.

This vulnerability was reported by Christoph Hochrainer via our Hackenproof bug bounty. We have evaluated the severity of the vulnerability as “Critical,” and paid a bounty. 

The fix for the circuit was implemented in [zirgen/pull/238](https://github.com/risc0/zirgen/pull/238), and the update to risc0 was implemented in [risc0/pull/3181](https://github.com/risc0/risc0/pull/3181). Impacted on-chain verifiers have already been disabled via the estop mechanism outlined in the [Verifier Management Design](https://github.com/risc0/risc0-ethereum/blob/release-2.0/contracts/version-management-design.md#base-verifier-implementations). 

## Mitigation
We recommend all impacted users upgrade as soon as possible.

Rust applications using the risc0-zkvm crate at versions 2.0.0, 2.0.1, and 2.0.2 should upgrade to version 2.1.0.

Smart contract applications using the official [RISC Zero Verifier Router](https://dev.risczero.com/api/blockchain-integration/contracts/verifier#verifier-router) do not need to take any action: zkVM version 2.1 is active on all official routers, and version 2.0 has been disabled.

Smart contract applications not using the verifier router should update their contracts to send verification calls to the 2.1 version of the verifier.
GitHub Security Advisory: GHSA-g3qg-6746-3mg9
Package: risc0-zkvm (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-345: Insufficient Verification of Data Authenticity
Vulnerable versions: >= 2.0.0, <= 2.0.2
Patched in: 2.1.0

Summary: zkVM Underconstrained Vulnerability

Details:
Due to a missing constraint in the rv32im circuit, any 3-register RISC-V instruction (including remu and divu) in risc0-zkvm 2.0.0, 2.0.1, and 2.0.2 are vulnerable to an attack by a malicious prover. The main idea for the attack is to confuse the RISC-V virtual machine into treating the value of the rs1 register as the same as the rs2 register due to a lack of constraints in the rv32im circuit.

This vulnerability was reported by Christoph Hochrainer via our Hackenproof bug bounty. We have evaluated the severity of the vulnerability as “Critical,” and paid a bounty. 

The fix for the circuit was implemented in [zirgen/pull/238](https://github.com/risc0/zirgen/pull/238), and the update to risc0 was implemented in [risc0/pull/3181](https://github.com/risc0/risc0/pull/3181). Impacted on-chain verifiers have already been disabled via the estop mechanism outlined in the [Verifier Management Design](https://github.com/risc0/risc0-ethereum/blob/release-2.0/contracts/version-management-design.md#base-verifier-implementations). 

## Mitigation
We recommend all impacted users upgrade as soon as possible.

Rust applications using the risc0-zkvm crate at versions 2.0.0, 2.0.1, and 2.0.2 should upgrade to version 2.1.0.

Smart contract applications using the official [RISC Zero Verifier Router](https://dev.risczero.com/api/blockchain-integration/contracts/verifier#verifier-router) do not need to take any action: zkVM version 2.1 is active on all official routers, and version 2.0 has been disabled.

Smart contract applications not using the verifier router should update their contracts to send verification calls to the 2.1 version of the verifier.
GitHub Security Advisory: GHSA-93c7-7xqw-w357
Package: pingora-core (RUST)
Severity: HIGH (CVSS 0.0)
CWE: CWE-444: Inconsistent Interpretation of HTTP Requests ('HTTP Request/Response Smuggling')
Vulnerable versions: < 0.5.0
Patched in: 0.5.0

Summary: Pingora has a Request Smuggling Vulnerability

Details:
A request smuggling vulnerability identified within Pingora’s proxying framework, pingora-proxy, allows malicious HTTP requests to be injected via manipulated request bodies on cache HITs, leading to unauthorized request execution and potential cache poisoning.

### Fixed in
https://github.com/cloudflare/pingora/commit/fda3317ec822678564d641e7cf1c9b77ee3759ff 

### Impact
The issue could lead to request smuggling in cases where Pingora’s proxying framework, pingora-proxy, is used for caching allowing an attacker to manipulate headers and URLs in subsequent requests made on the same HTTP/1.1 connection.