deardaniel/secdata-raw huggingface dataset:
GitHub Security Advisory: GHSA-29x4-r6jv-ff4w
Package: zebrad (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-248: Uncaught Exception, CWE-617: Reachable Assertion
Vulnerable versions: >= 2.2.0, < 4.3.1
Patched in: 4.3.1

Summary: Zebra Vulnerable to Denial of Service via Interrupted JSON-RPC Requests from Authenticated Clients

Details:
A vulnerability in Zebra's JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response.

## Severity
**Moderate** - This is a Denial of Service (DoS) that requires a client capable of passing Zebra's cookie authentication, which is enabled by default.

## Affected Versions
- `zebrad`: versions from **2.2.0** up to (but not including) **4.3.1**
- `zebra-rpc`: versions from **1.0.0-beta.45** up to (but not including) **6.0.2**

## Description

Zebra's JSON-RPC HTTP middleware treated a failure to read the incoming HTTP request body as an unrecoverable error, aborting the process rather than returning an error response. A client that disconnected after sending only part of a request body, for example, by resetting the TCP connection mid-transfer, was sufficient to trigger the crash. The vulnerability could be exploited only by authenticated RPC clients. Nodes running the shipped defaults, with RPC bound to localhost and cookie authentication on, were not vulnerable.

## Impact
**Denial of Service**
* **Attack Vector:** Network, authenticated (requires a valid RPC cookie when cookie authentication is enabled).
* **Effect:** Immediate crash of the Zebra node.
* **Scope:** Any node whose RPC interface is reachable by a client with valid credentials, or any node with cookie authentication disabled and an exposed RPC interface.

## Fixed Versions
This issue is fixed in **Zebra 4.3.1** (crate `zebra-rpc` 6.0.2).

The fix propagates failures to read the HTTP request body as ordinary error responses, so Zebra now rejects truncated or interrupted requests rather than crashing.

## Mitigation
Users should upgrade to **Zebra 4.3.1** or later.

If an immediate upgrade is not possible, users should ensure their RPC port is not exposed to untrusted networks and that cookie authentication remains enabled (the default).

## References
* [Zebra 4.3.1 Release Announcement](https://zfnd.org/)

## Credits
Thanks to [shieldedonly](https://github.com/shieldedonly) who discovered this issue and reported it via our coordinated disclosure process.
GitHub Security Advisory: GHSA-29x4-r6jv-ff4w
Package: zebra-rpc (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-248: Uncaught Exception, CWE-617: Reachable Assertion
Vulnerable versions: >= 1.0.0-beta.45, < 6.0.2
Patched in: 6.0.2

Summary: Zebra Vulnerable to Denial of Service via Interrupted JSON-RPC Requests from Authenticated Clients

Details:
A vulnerability in Zebra's JSON-RPC HTTP middleware allows an authenticated RPC client to cause a Zebra node to crash by disconnecting before the request body is fully received. The node treats the failure to read the HTTP request body as an unrecoverable error and aborts the process instead of returning an error response.

## Severity
**Moderate** - This is a Denial of Service (DoS) that requires a client capable of passing Zebra's cookie authentication, which is enabled by default.

## Affected Versions
- `zebrad`: versions from **2.2.0** up to (but not including) **4.3.1**
- `zebra-rpc`: versions from **1.0.0-beta.45** up to (but not including) **6.0.2**

## Description

Zebra's JSON-RPC HTTP middleware treated a failure to read the incoming HTTP request body as an unrecoverable error, aborting the process rather than returning an error response. A client that disconnected after sending only part of a request body, for example, by resetting the TCP connection mid-transfer, was sufficient to trigger the crash. The vulnerability could be exploited only by authenticated RPC clients. Nodes running the shipped defaults, with RPC bound to localhost and cookie authentication on, were not vulnerable.

## Impact
**Denial of Service**
* **Attack Vector:** Network, authenticated (requires a valid RPC cookie when cookie authentication is enabled).
* **Effect:** Immediate crash of the Zebra node.
* **Scope:** Any node whose RPC interface is reachable by a client with valid credentials, or any node with cookie authentication disabled and an exposed RPC interface.

## Fixed Versions
This issue is fixed in **Zebra 4.3.1** (crate `zebra-rpc` 6.0.2).

The fix propagates failures to read the HTTP request body as ordinary error responses, so Zebra now rejects truncated or interrupted requests rather than crashing.

## Mitigation
Users should upgrade to **Zebra 4.3.1** or later.

If an immediate upgrade is not possible, users should ensure their RPC port is not exposed to untrusted networks and that cookie authentication remains enabled (the default).

## References
* [Zebra 4.3.1 Release Announcement](https://zfnd.org/)

## Credits
Thanks to [shieldedonly](https://github.com/shieldedonly) who discovered this issue and reported it via our coordinated disclosure process.
GitHub Security Advisory: GHSA-452v-w3gx-72wg
Package: zebra-chain (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-617: Reachable Assertion
Vulnerable versions: < 6.0.2
Patched in: 6.0.2

Summary: Zebra has rk Identity Point Panic in Transaction Verification

Details:
# rk Identity Point Panic in Transaction Verification

## Summary

Orchard transactions contain a `rk` field which is a randomized validating key and also an elliptic curve point. The Zcash specification allows the field to be the identity (a "zero" value), however, the `orchard` crate which is used to verify Orchard proofs would panic when fed a `rk` with the identity value. Thus an attacker could send a crafted transaction that would make a Zebra node crash.

## Severity

**Critical** - This is a Denial of Service Vulnerability that could allow an attacker to crash Zebra nodes.

## Affected Versions

All Zebra versions prior to **version 4.3.1**.

## Description

The vulnerability exists in the `circuits.rs` file of the `orchard` crate; it attempts to get the coordinates of the `rk` value and calls `unwrap()` on the results, which causes a panic if `rk` is the identity.

Zebra parses `rk` as a byte vector; it creates an Orchard "bundle" using the `orchard` crate and then calls the same crate to verify it, triggering the panic.

An attacker could exploit this by:
1. Creating a transaction with a identity `rk`
2. Submitting it to a Zebra node, making it crash

## Impact

**Denial of Service**

* **Attack Vector:** Network.
* **Effect:** Node crash.
* **Scope:** Any impacted Zebra node.

## Fixed Versions

This issue is fixed in **Zebra 4.3.1**. 

The fix was agreed with `zcashd` developers (which has the same issue) to not allow the identity `rk` anymore and change the specification as such. Zebra now does this when parsing a transaction. This was deemed easier than fixing the issue in `orchard`, which would make the bug public before the nodes could be patched.

## Mitigation

Users should upgrade to **Zebra 4.3.1** or later immediately. 

There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains not vulnerable to denial of service.

## Credits

Thanks to Alex “Scalar” Sol for finding and reporting the issue.
GitHub Security Advisory: GHSA-452v-w3gx-72wg
Package: zebrad (RUST)
Severity: CRITICAL (CVSS 0.0)
CWE: CWE-617: Reachable Assertion
Vulnerable versions: < 4.3.1
Patched in: 4.3.1

Summary: Zebra has rk Identity Point Panic in Transaction Verification

Details:
# rk Identity Point Panic in Transaction Verification

## Summary

Orchard transactions contain a `rk` field which is a randomized validating key and also an elliptic curve point. The Zcash specification allows the field to be the identity (a "zero" value), however, the `orchard` crate which is used to verify Orchard proofs would panic when fed a `rk` with the identity value. Thus an attacker could send a crafted transaction that would make a Zebra node crash.

## Severity

**Critical** - This is a Denial of Service Vulnerability that could allow an attacker to crash Zebra nodes.

## Affected Versions

All Zebra versions prior to **version 4.3.1**.

## Description

The vulnerability exists in the `circuits.rs` file of the `orchard` crate; it attempts to get the coordinates of the `rk` value and calls `unwrap()` on the results, which causes a panic if `rk` is the identity.

Zebra parses `rk` as a byte vector; it creates an Orchard "bundle" using the `orchard` crate and then calls the same crate to verify it, triggering the panic.

An attacker could exploit this by:
1. Creating a transaction with a identity `rk`
2. Submitting it to a Zebra node, making it crash

## Impact

**Denial of Service**

* **Attack Vector:** Network.
* **Effect:** Node crash.
* **Scope:** Any impacted Zebra node.

## Fixed Versions

This issue is fixed in **Zebra 4.3.1**. 

The fix was agreed with `zcashd` developers (which has the same issue) to not allow the identity `rk` anymore and change the specification as such. Zebra now does this when parsing a transaction. This was deemed easier than fixing the issue in `orchard`, which would make the bug public before the nodes could be patched.

## Mitigation

Users should upgrade to **Zebra 4.3.1** or later immediately. 

There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains not vulnerable to denial of service.

## Credits

Thanks to Alex “Scalar” Sol for finding and reporting the issue.
GitHub Security Advisory: GHSA-xr93-pcq3-pxf8
Package: zebra-network (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 5.0.1
Patched in: 5.0.1

Summary: Zebra: addr/addrv2 Deserialization Resource Exhaustion

Details:
# CVE-2026-40881: addr/addrv2 Deserialization Resource Exhaustion

## Summary

When deserializing `addr` or `addrv2` messages, which contain vectors of addresses, Zebra would fully deserialize them up to a maximum length (over 233,000) that was derived from the 2 MiB message size limit. This is much larger than the actual limit of 1,000 messages from the specification. Zebra would eventually check that limit but, at that point, the memory for the larger vector was already allocated. An attacker could cause out-of-memory aborts in Zebra by sending multiple such messages over different connections.

## Severity

**Moderate** - This is a Denial of Service Vulnerability that could allow an attacker to crash a Zebra node.

## Affected Versions

All Zebra versions prior to **version 4.3.1**.

## Description

The vulnerability exists in the `read_addr/addrv2` functions in `codec.rs`. It deserializes a vector of addresses with the `zcash_deserialize()` trait method, which uses as a upper bound the result of `T::max_allocation()`. For theses types, it was derived from dividing the max message size (2 MiB) by the minimum serialized size of one entry. For AddrV1: 2_097_152 / 30 = 69,904. For AddrV2: 2_097_152 / 9 = 233,016. Only after deserialization was the `MAX_ADDRS_IN_MESSAGE = 1000` limit checked.

An attacker could exploit this by:
1. Creating `addr` or `addrv2` messages with a large number of entries.
2. Submitting them to a Zebra node, possibly through multiple connections, to attempt to get Zebra into an out-of-memory state.

## Impact

**Denial of Service**

* **Attack Vector:** Network.
* **Effect:** Zebra node crash.
* **Scope:** Any impacted Zebra node.

## Fixed Versions

This issue is fixed in **Zebra 4.3.1**. 

The fix changes the `max_allocation()` method for the relevant types to return 1,000, thus blocking larger values prior to deserialization.

## Mitigation

Users should upgrade to **Zebra 4.3.1** or later immediately. 

There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains not vulnerable to the denial of service attack.

## Credits

Thanks @Zk-nd3r for finding and reporting the issue, and suggesting the fix.
GitHub Security Advisory: GHSA-xr93-pcq3-pxf8
Package: zebrad (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-770: Allocation of Resources Without Limits or Throttling
Vulnerable versions: < 4.3.1
Patched in: 4.3.1

Summary: Zebra: addr/addrv2 Deserialization Resource Exhaustion

Details:
# CVE-2026-40881: addr/addrv2 Deserialization Resource Exhaustion

## Summary

When deserializing `addr` or `addrv2` messages, which contain vectors of addresses, Zebra would fully deserialize them up to a maximum length (over 233,000) that was derived from the 2 MiB message size limit. This is much larger than the actual limit of 1,000 messages from the specification. Zebra would eventually check that limit but, at that point, the memory for the larger vector was already allocated. An attacker could cause out-of-memory aborts in Zebra by sending multiple such messages over different connections.

## Severity

**Moderate** - This is a Denial of Service Vulnerability that could allow an attacker to crash a Zebra node.

## Affected Versions

All Zebra versions prior to **version 4.3.1**.

## Description

The vulnerability exists in the `read_addr/addrv2` functions in `codec.rs`. It deserializes a vector of addresses with the `zcash_deserialize()` trait method, which uses as a upper bound the result of `T::max_allocation()`. For theses types, it was derived from dividing the max message size (2 MiB) by the minimum serialized size of one entry. For AddrV1: 2_097_152 / 30 = 69,904. For AddrV2: 2_097_152 / 9 = 233,016. Only after deserialization was the `MAX_ADDRS_IN_MESSAGE = 1000` limit checked.

An attacker could exploit this by:
1. Creating `addr` or `addrv2` messages with a large number of entries.
2. Submitting them to a Zebra node, possibly through multiple connections, to attempt to get Zebra into an out-of-memory state.

## Impact

**Denial of Service**

* **Attack Vector:** Network.
* **Effect:** Zebra node crash.
* **Scope:** Any impacted Zebra node.

## Fixed Versions

This issue is fixed in **Zebra 4.3.1**. 

The fix changes the `max_allocation()` method for the relevant types to return 1,000, thus blocking larger values prior to deserialization.

## Mitigation

Users should upgrade to **Zebra 4.3.1** or later immediately. 

There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains not vulnerable to the denial of service attack.

## Credits

Thanks @Zk-nd3r for finding and reporting the issue, and suggesting the fix.
GitHub Security Advisory: GHSA-xgp8-3hg3-c2mh
Package: rustls-webpki (RUST)
Severity: LOW (CVSS 2.2)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: >= 0.104.0-alpha.1, < 0.104.0-alpha.6
Patched in: 0.104.0-alpha.6

Summary: webpki: Name constraints were accepted for certificates asserting a wildcard name

Details:
Permitted subtree name constraints for DNS names were accepted for certificates asserting a wildcard name.

This was incorrect because, given a name constraint of `accept.example.com`, `*.example.com` could feasibly allow a name of `reject.example.com` which is outside the constraint.
This is very similar to [CVE-2025-61727](https://go.dev/issue/76442).

Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.
GitHub Security Advisory: GHSA-xgp8-3hg3-c2mh
Package: rustls-webpki (RUST)
Severity: LOW (CVSS 2.2)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: >= 0.101.0, < 0.103.12
Patched in: 0.103.12

Summary: webpki: Name constraints were accepted for certificates asserting a wildcard name

Details:
Permitted subtree name constraints for DNS names were accepted for certificates asserting a wildcard name.

This was incorrect because, given a name constraint of `accept.example.com`, `*.example.com` could feasibly allow a name of `reject.example.com` which is outside the constraint.
This is very similar to [CVE-2025-61727](https://go.dev/issue/76442).

Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.
GitHub Security Advisory: GHSA-965h-392x-2mh5
Package: rustls-webpki (RUST)
Severity: LOW (CVSS 2.2)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: >= 0.104.0-alpha.1, < 0.104.0-alpha.6
Patched in: 0.104.0-alpha.6

Summary: webpki: Name constraints for URI names were incorrectly accepted

Details:
Name constraints for URI names were ignored and therefore accepted.

Note this library does not provide an API for asserting URI names, and URI name constraints are otherwise not implemented.  URI name constraints are now rejected unconditionally.

Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.
GitHub Security Advisory: GHSA-965h-392x-2mh5
Package: rustls-webpki (RUST)
Severity: LOW (CVSS 2.2)
CWE: CWE-295: Improper Certificate Validation
Vulnerable versions: >= 0.101.0, < 0.103.12
Patched in: 0.103.12

Summary: webpki: Name constraints for URI names were incorrectly accepted

Details:
Name constraints for URI names were ignored and therefore accepted.

Note this library does not provide an API for asserting URI names, and URI name constraints are otherwise not implemented.  URI name constraints are now rejected unconditionally.

Since name constraints are restrictions on otherwise properly-issued certificates, this bug is reachable only after signature verification and requires misissuance to exploit.
GitHub Security Advisory: GHSA-cq8v-f236-94qc
Package: rand (RUST)
Severity: LOW (CVSS 0.0)
CWE: CWE-20: Improper Input Validation
Vulnerable versions: = 0.10.0
Patched in: 0.10.1

Summary: Rand is unsound with a custom logger using rand::rng()

Details:
It has been reported (by @lopopolo) that the `rand` library is [unsound](https://rust-lang.github.io/unsafe-code-guidelines/glossary.html#soundness-of-code--of-a-library) (i.e. that safe code using the public API can cause Undefined Behaviour) when all the following conditions are met:

- The `log` and `thread_rng` features are enabled
- A [custom logger](https://docs.rs/log/latest/log/#implementing-a-logger) is defined
- The custom logger accesses `rand::rng()` (previously `rand::thread_rng()`) and calls any `TryRng` (previously `RngCore`) methods on `ThreadRng`
- The `ThreadRng` (attempts to) reseed while called from the custom logger (this happens every 64 kB of generated data)
- Trace-level logging is enabled or warn-level logging is enabled and the random source (the `getrandom` crate) is unable to provide a new seed

`TryRng` (previously `RngCore`) methods for `ThreadRng` use `unsafe` code to cast `*mut BlockRng<ReseedingCore>` to `&mut BlockRng<ReseedingCore>`. When all the above conditions are met this results in an aliased mutable reference, violating the Stacked Borrows rules. Miri is able to detect this violation in sample code. Since construction of [aliased mutable references is Undefined Behaviour](https://doc.rust-lang.org/stable/nomicon/references.html), the behaviour of optimized builds is hard to predict.
GitHub Security Advisory: GHSA-48m6-486p-9j8p
Package: nimiq-consensus (RUST)
Severity: MODERATE (CVSS 5.3)
CWE: CWE-617: Reachable Assertion
Vulnerable versions: <= 1.2.2
Patched in: unpatched

Summary: nimiq-consensus panics via RequestMacroChain micro-block locator

Details:
### Impact
 An unauthenticated p2p peer can cause the `RequestMacroChain` message handler task to panic by sending a `RequestMacroChain` message where the first locator hash that is on the victim’s main chain is a micro block hash (not a macro block hash).

In `RequestMacroChain::handle`, the handler selects the locator based only on "is on main chain", then calls `get_macro_blocks()` and panics via `.unwrap()` when the selected hash is not a macro block (`BlockchainError::BlockIsNotMacro`).

### Patches
The patch for this vulnerability](https://github.com/nimiq/core-rs-albatross/pull/3660) is formally released as part of [v1.3.0](https://github.com/nimiq/core-rs-albatross/releases/tag/v1.3.0).

### Workarounds
No known workarounds.
GitHub Security Advisory: GHSA-49xc-52mp-cc9j
Package: nimiq-blockchain (RUST)
Severity: CRITICAL (CVSS 9.1)
CWE: CWE-20: Improper Input Validation, CWE-1284: Improper Validation of Specified Quantity in Input
Vulnerable versions: <= 1.3.0
Patched in: unpatched

Summary: nimiq-blockchain is missing a wall-clock upper bound on block timestamps

Details:
### Impact

Block timestamp validation enforces that `timestamp >= parent.timestamp` for non-skip blocks and `timestamp == parent.timestamp + MIN_PRODUCER_TIMEOUT` for skip blocks, but there is no visible upper bound check against the wall clock. A malicious block-producing validator can set block timestamps arbitrarily far in the future. This directly affects reward calculations via `Policy::supply_at()` and `batch_delay()` in `blockchain/src/reward.rs`, inflating the monetary supply beyond the intended emission schedule.

### Patches
TBD

### Workarounds
No know workarounds.
GitHub Security Advisory: GHSA-f984-pcp8-v2p7
Package: wasmtime (RUST)
Severity: MODERATE (CVSS 0.0)
CWE: CWE-789: Memory Allocation with Excessive Size Value
Vulnerable versions: = 43.0.0
Patched in: 43.0.1

Summary: Wasmtime has improperly masked return value from `table.grow` with Winch compiler backend

Details:
### Impact

Wasmtime's Winch compiler backend contains a bug where translating the `table.grow` operator causes the result to be incorrectly typed. For 32-bit tables this means that the result of the operator, internally in Winch, is tagged as a 64-bit value instead of a 32-bit value. This invalid internal representation of Winch's compiler state compounds into further issues depending on how the value is consumed.

One example can be seen when the result of `table.grow` is used as the address of a load operation. The load operation is tricked into thinking the address is a 64-bit value, not a 32-bit value, which means that the final address to load from is calculated incorrectly. This can lead to a situation where the bytes before the start of linear memory can be loaded/stored to.

The primary consequence of this bug is that bytes in the host's address space can be stored/read from. This is only applicable to the 16 bytes before linear memory, however, as the only significant return value of `table.grow` that can be misinterpreted is -1. The bytes before linear memory are, by default, unmapped memory. Wasmtime will detect this fault and abort the process, however, because wasm should not be able to access these bytes.

Overall this this bug in Winch represents a DoS vector by crashing the host process, a correctness issue within Winch, and a possible leak of up to 16-bytes before linear memory. Wasmtime's default compiler is Cranelift, not Winch, and Wasmtime's default settings are to place guard pages before linear memory. This means that Wasmtime's default configuration is not affected by this issue, and when explicitly choosing Winch Wasmtime's otherwise default configuration leads to a DoS. Disabling guard pages before linear memory is required to possibly leak up to 16-bytes of host data.

### Patches

Wasmtime 43.0.1, 42.0.2, and 36.0.7 have been released with fixes for this issue.

### Workaround

There are no workarounds within the Winch compiler backend while using the affected versions. Users of Wasmtime are encouraged either to upgrade to patched versions or, if that is not possible, use the Cranelift compiler backend.