CVE-2026-52732 in Zebra
Summary
by MITRE • 08/18/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/19/2026
The vulnerability identified in Zebra versions prior to 4.5.0 represents a significant resource exhaustion flaw within the peer-to-peer networking layer of this Rust-based Zcash node implementation. The core technical deficiency lies in the architecture of the inbound mempool download and verification pipeline, specifically how it manages concurrency limits for incoming transactions. Prior to the fix, the system utilized a bounded queue designed to handle up to twenty-five concurrent inbound connections as defined by MAX_INBOUND_CONCURRENCY. However, this limit was applied globally rather than on a per-peer basis. This architectural oversight meant that there were no mechanisms in place to track or restrict the number of pending requests originating from any single peer identity. Consequently, an unauthenticated remote attacker could exploit this lack of granularity by advertising fake transaction identifiers through standard gossip protocols. Because the node did not associate these download tasks with specific peers, it treated each request as a legitimate candidate for processing regardless of its source.
The operational mechanics of this denial-of-service attack rely on timing and state manipulation within the queue management system. When an attacker advertises invalid or non-existent transaction hashes, Zebra initiates download attempts from various peers to retrieve these transactions. Since peer identity is not carried through Gossip messages and FullQueue responses are mapped to Response::Nil rather than triggering appropriate overload disconnection logic, the node continues to allocate resources for these futile requests. Each failed attempt holds a slot in the bounded queue until it times out according to TRANSACTION_DOWNLOAD_TIMEOUT settings. By continuously advertising new fake transaction identifiers as slots expire due to timeouts, an attacker can maintain persistent saturation of all twenty-five inbound concurrency slots. This creates a sustained state where the pipeline is effectively blocked by maliciously generated load that consumes memory and processing time without delivering any valid data.
The impact on network operations during such an attack is severe for honest participants in the Zcash ecosystem. While block validation and synchronization processes continue to function normally, ensuring that the node remains synchronized with the blockchain ledger, local transaction propagation is effectively halted. Honest peers attempting to broadcast transactions or users submitting requests via sendrawtransaction are rejected because the mempool queue is full. This results in a MempoolError::FullQueue response being returned to legitimate actors. The practical consequence is a localized denial of service where honest network participants cannot propagate their transactions, leading to delayed confirmations and potential financial loss for those relying on timely transaction inclusion. Although the node itself remains operational and does not crash, its utility as a reliable relay point for mempool data is compromised during the attack window.
This vulnerability aligns with CWE-400, which describes Uncontrolled Resource Consumption, specifically manifesting as resource exhaustion through unbounded allocation of connection slots without proper per-client accounting. From an offensive security perspective, this behavior corresponds to ATT&CK technique T1496, Resource Hijacking, where the attacker consumes system resources to degrade service availability for legitimate users. The root cause is a failure in input validation and state management within the peer-to-peer communication layer, highlighting the importance of strict identity tracking even when dealing with untrusted network peers. To mitigate this class of vulnerability, developers must implement per-peer accounting mechanisms that track active download tasks associated with each connection ID. Additionally, enforcing stricter limits on the number of concurrent requests allowed from a single IP address or peer identifier would prevent any individual actor from monopolizing shared resources. The issue was resolved in Zebra version 4.5.0 by introducing these necessary controls to ensure fair resource distribution and robust handling of malformed or malicious network traffic.