CVE-2026-52736 in Zebra
Summary
by MITRE • 08/18/2026
ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, a remote unauthenticated P2P peer can stall a Zebra node by racing an invalid block body against the valid canonical body for the same block header hash. ZIP-244 permits the attacker to mutate coinbase scriptSig authentication data while retaining the transaction identifiers, merkle root, and block header hash, so the poisoned body fails later commitment validation but shares the canonical hash. In zebra-state/src/service.rs, queue_and_commit_to_non_finalized_state recorded the hash in non_finalized_block_write_sent_hashes before contextual validation completed and did not remove it when the write task rejected the body. When the honest body later arrived, the cached hash caused KnownBlock::WriteChannel duplicate handling to suppress it, leaving the node stuck one height behind until restart or reorganization. This issue is fixed in version 4.5.0.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in Zebra versions prior to 4.5.0 represents a significant denial of service risk within the peer-to-peer networking layer of this Rust-based Zcash node implementation. The core flaw stems from an improper handling of block validation state during concurrent processing, specifically involving the interaction between network message reception and internal state management. An unauthenticated remote attacker can exploit this by submitting two distinct block bodies that share the same valid block header hash but contain different transaction data. This technique leverages ZIP-244 specifications which allow for mutations in coinbase scriptSig authentication data while preserving critical identifiers such as transaction IDs, merkle roots, and the block header hash itself. By racing an invalid body against a legitimate one, the attacker creates a scenario where the node processes conflicting versions of what appears to be the same block based on its cryptographic signature.
The technical mechanism of this exploit relies on a race condition within the zebra-state service module, specifically in the queue_and_commit_to_non_finalized_state function. When an invalid block body is received and queued for contextual validation, the system prematurely records the block's hash into the non_finalized_block_write_sent_hashes collection before the actual validation process completes. Crucially, if the subsequent contextual validation rejects this poisoned body due to commitment failures or other integrity checks, the implementation fails to remove the associated hash from the tracking set. This creates a stale state entry that persists in memory despite the block being deemed invalid by the consensus rules.
The operational impact of this flaw is severe for network stability and node synchronization. When the legitimate canonical block body eventually arrives over the P2P network, it shares the same header hash as the previously rejected malicious attempt. The node's internal logic checks against the non_finalized_block_write_sent_hashes set to prevent duplicate processing. Because the invalid entry was never cleaned up, the system incorrectly identifies the valid incoming block as a known duplicate write channel event. Consequently, the honest body is suppressed and discarded rather than being processed into the blockchain state. This results in the node becoming stuck one height behind the network tip, effectively halting its synchronization progress until it is manually restarted or undergoes a complex reorganization to clear the erroneous state.
This vulnerability aligns with CWE-362, which describes concurrent execution race conditions leading to unintended behavior, and specifically impacts the availability component of the CIA triad by rendering the node unresponsive to new blocks without external intervention. From an ATT&CK perspective, this falls under T1498 Network Denial of Service as it allows a single actor to disrupt service for that specific node through resource exhaustion via state corruption rather than simple bandwidth flooding. The fix implemented in version 4.5.0 addresses the root cause by ensuring that hashes are only retained if their corresponding block bodies pass full contextual validation, thereby preventing stale entries from blocking legitimate network traffic and restoring normal synchronization capabilities to affected nodes.