CVE-2026-52736

The vulnerability in Zebra versions before 4.5.0 stems from a race between premature hash caching and incomplete rejection cleanup in the non-finalized state system. When a peer sends a block, Zebra records its hash in `non_finalized_block_write_sent_hashes` before contextual validation completes—optimized for honest P2P performance. If the block body is rejected during later validation (for example, failing ZIP-244 coinbase commitment checks), the hash remains cached. This is the critical gap: the recording path is eager, but rejection cleanup was not equivalently rigorous. An attacker exploits this by sending a poisoned block body that shares a header hash with an honest block but fails commitment validation. The poisoned body gets recorded in the cache, gets rejected, and leaves a stale hash entry. When the legitimate body arrives, the duplicate suppression logic in `KnownBlock::WriteChannel` sees the cached hash and drops it—the node stalls with a different view of the chain tip than the network. In Zcash's privacy-focused context, this information asymmetry is the actual blast radius, not merely the technical stall. The 4.5.0 patch adds cleanup to the rejection path, which closes this specific vector. However, the underlying architectural bet remains: non-finalized state still records hashes before validation completes. The protocol continues to permit mutation spaces (ZIP-244's coinbase scriptSig mutations, and likely future extensions) that preserve some hashes but not others. This means the same pattern could recur with the next protocol change that introduces new mutations. For defenders, the priority is immediate upgrade to 4.5.0. Beyond patching, audit your non-finalized state code paths for similar pre-validation caching patterns—if other components record data optimistically before validation, check whether their rejection paths properly clean up. More broadly, treat protocol changes that expand mutation space as triggering mandatory re-audit of existing state management code, not just cryptographic review. The vulnerability emerged because ZIP-244 introduced new mutations into a code base that pre-dated them and was never re-audited against the expanded threat model. The fix is correct and necessary; treating it as sufficient is the remaining risk.

Reviewed through automated stages and approved by a human before publication.