Zebra CVE-2026-40880

Exploitation requires the targeted Zebra node (version <4.3.1) to have previously accepted the malicious transaction into its mempool, thereby populating the verification cache. The attacker must control mining capability sufficient to produce two consecutive blocks (probabilistically achievable with sustained hashrate or stake). The attack targets the specific transaction verification cache optimization for V5 transactions introduced in Zebra's NU5 network upgrade support. Nodes running zcashd or Zebra instances that rejected or never received the malicious transaction in their mempool are immune-consensus validation proceeds normally without cached results. The out-of-order block submission (H+2 before H+1) is critical; normal sequential block propagation would trigger different validation code paths. The vulnerability is specific to Zebra's Rust-based architecture and does not affect zcashd's C++ codebase. Geographic or network topology factors are irrelevant-any internet-connected Zebra node with the cached transaction is vulnerable. Default Zebra configurations are affected with no special settings required to enable the vulnerable code path.

High real-world risk despite missing quantitative metrics (no CVSS score, EPSS data, or KEV listing). Consensus vulnerabilities in cryptocurrency nodes are critical because they enable network partitioning and double-spend attacks-the fundamental security failures blockchain systems are designed to prevent. Attack complexity is HIGH: requires mining capability (expensive proof-of-work or stake investment), precise timing to submit blocks out-of-order, and foreknowledge of which Zebra nodes have cached the malicious transaction. Privileges required are NONE from a network perspective, but economic cost (mining hardware/stake) creates practical barrier. Technical impact is TOTAL for affected nodes (complete consensus failure, potential financial loss from accepting invalid chain). SSVC decision: exploitation status NONE (no public exploits), automatable NO (requires mining resources), technical impact TOTAL (consensus layer). However, attack surface is LIMITED-only Zebra nodes that accepted the malicious transaction into their mempool are vulnerable; nodes running zcashd or Zebra instances without that mempool entry remain protected. The vendor correctly assessed this as HIGH severity and removed the optimization rather than attempting a surgical fix, indicating low confidence in the attack surface boundaries. Real-world exploitation would likely be targeted (specific victim nodes) rather than network-wide, explaining absence from KEV despite consensus impact.

A malicious Zcash miner controlling significant hashrate crafts a transaction with expiry height 2,500,001 and broadcasts it to the network when the current blockchain tip is at height 2,500,000. Zebra nodes accepting this transaction into their mempool cache it as 'verified valid.' The attacker then mines two blocks: a legitimate block 2,500,001 and a poisoned block 2,500,002 containing the now-expired transaction. The attacker submits block 2,500,002 first-vulnerable Zebra nodes place it in the pending queue awaiting its parent. When block 2,500,001 arrives, Zebra performs contextual verification of the pending block 2,500,002, but the cached verification result bypasses expiry height checks. Vulnerable Zebra nodes commit both blocks, accepting an invalid chain. Honest zcashd nodes and Zebra nodes without the mempool entry correctly reject block 2,500,002 as containing an expired transaction. The attacker's mining pool now has isolated a subset of network nodes onto a minority fork, enabling double-spend attacks against exchanges or merchants running vulnerable Zebra instances. No public proof-of-concept exists, but the attack is fully detailed in the vendor advisory with multiple independent security researchers confirming the mechanism.