Most recent entries from all

EUVD-2026-355201

fkie_cve-2026-52732

ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, one unauthenticated P2P peer can monopolize all 25 MAX_INBOUND_CONCURRENCY slots in Zebra's inbound mempool download and verification pipeline. In zebrad/src/components/mempool/downloads.rs, the bounded queue was shared globally without per-peer accounting, while peer identity was not carried through Gossip and FullQueue responses were mapped to Response::Nil instead of reaching overload disconnection handling. An attacker can advertise fake transaction identifiers and remain silent so each task holds a slot until TRANSACTION_DOWNLOAD_TIMEOUT, then periodically refill the queue as slots expire. While saturated, honest peer transactions and local sendrawtransaction requests are rejected with MempoolError::FullQueue, although block validation and synchronization continue. This issue is fixed in version 4.5.0.

GHSA-4fc2-h7jh-287c — zebrad has mempool transaction admission denial via single-peer inbound queue saturation

Affected: crates.io: zebrad

### Am I affected

You are affected if:

1. You run `zebrad` up to and including `v4.4.1`. 2. Your node accepts inbound P2P connections (`network.listen_addr` is set, which is the default). 3. Your node's mempool is active (node is synced near the chain tip).

All default configurations are affected.

### Summary

A single unauthenticated P2P peer can monopolize all 25 inbound mempool download/verification slots (`MAX_INBOUND_CONCURRENCY`) by advertising fake transaction IDs. While the slots are occupied, all other inbound transactions from honest peers and local RPC `sendrawtransaction` calls are rejected with `MempoolError::FullQueue`. The attacker peer is never scored for misbehavior and is not disconnected, allowing sustained denial of mempool admission.

### Details

The mempool download/verification pipeline at `zebrad/src/components/mempool/downloads.rs` uses a single bounded pool of 25 concurrent tasks. Three architectural gaps combine to produce the vulnerability:

1. No per-peer accounting: the 25 slots are shared across all peers with no cap on how many a single peer can hold. 2. No overload signaling: when `FullQueue` is returned, the inbound service at `zebrad/src/components/inbound.rs` maps it to `Response::Nil`, hiding the overload from the peer connection layer. The existing `handle_inbound_overload` disconnection logic never fires. 3. No misbehavior attribution: peer identity is not carried through the `Gossip` type into the download pipeline, so verificatio…