CVE-2026-40880
Rust vulnerability analysis and mitigation

Overview

CVE-2026-40880 is a consensus vulnerability in the Zcash Foundation's Zebra node implementation, titled "Cached Mempool Verification Bypasses Consensus Rules for Ahead-of-Tip Blocks." A logic error in Zebra's transaction verification cache allows a malicious miner to craft a transaction valid at block height H+1 but invalid at H+2, then mine it into a block at H+2, causing vulnerable Zebra nodes to accept an invalid block and split from the rest of the Zcash network. Affected packages are zebra-consensus (Rust, versions < 5.0.2) and zebrad (Rust, versions < 4.3.1). The vulnerability was published on April 17–18, 2026, and assigned a CVSS v3.1 score of 8.1 (High) and a CVSS v4.0 score of 7.2 (High) (GitHub Advisory, Zebra Advisory).

Technical details

The root cause is classified as CWE-1025 (Comparison Using Wrong Factors): a performance optimization in Zebra's transaction verification cache skips re-validation of transactions previously accepted into the mempool, without accounting for height-dependent validity conditions such as expiry height, lock time, and network upgrade bindings (GitHub Advisory). An attacker exploits this by submitting a transaction with expiry height H+1, then mining blocks H+1 and H+2 (where H+2 contains the now-expired transaction) and broadcasting H+2 before H+1; Zebra nodes with the transaction cached accept H+2 as valid and later commit both blocks, including the invalid one (Zebra Advisory). Exploitation requires the attacker to have mining capability (low privilege, but a specific role) and targets only Zebra nodes using the V5 transaction verification cache optimization. The fix removes the performance optimization entirely, ensuring full transaction integrity — including authorization data — is always validated against the current block height (GitHub Advisory).

Impact

Successful exploitation causes a consensus split, isolating vulnerable Zebra nodes from the broader Zcash network by causing them to accept blocks that other nodes (e.g., zcashd or unaffected zebrad instances) reject. This results in high integrity and availability impact: the affected node operates on a forked chain, undermining the trustworthiness of its blockchain state and rendering it unable to participate correctly in network consensus. The advisory also notes the potential for double-spend attacks against affected nodes, as the forked chain state could be leveraged to manipulate transaction finality (GitHub Advisory, Zebra Advisory).

Exploitability

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time (Feedly). Exploitation requires the attacker to be a functioning miner on the Zcash network, which limits the attacker pool but does not make exploitation infeasible. The EPSS score is approximately 0.042–0.054%, placing it in the 17th percentile for exploitation probability within 30 days (GitHub Advisory). The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog, and no threat actor attribution has been reported.

Exploitation steps

  1. Acquire mining capability: The attacker must operate as a miner on the Zcash network, with the ability to construct and broadcast custom blocks and transactions.
  2. Craft a height-sensitive transaction: Create a V5 transaction with an expiry height of H+1 (where H is the current chain tip), ensuring it is valid at H+1 but invalid at H+2 due to expiry, lock time, or network upgrade constraints.
  3. Broadcast the transaction to target nodes: Submit the crafted transaction to the Zcash P2P network so that vulnerable Zebra nodes accept it into their mempools and cache its verification result.
  4. Mine blocks H+1 and H+2: Construct block H+1 (which may or may not include the transaction) and block H+2 that includes the now-expired transaction.
  5. Submit H+2 before H+1: Broadcast block H+2 to the network before H+1, exploiting the cache: Zebra nodes with the transaction cached accept H+2 as valid (pending contextual verification) and queue it.
  6. Trigger consensus split: When block H+1 arrives, vulnerable Zebra nodes commit both H+1 and H+2 — including the invalid transaction — while other nodes (zcashd, unaffected zebrad) reject H+2, causing the poisoned Zebra node to fork onto an invalid chain (GitHub Advisory, Zebra Advisory).

Indicators of compromise

  • Network: Zebra node peers with unexpected chain tip divergence from the rest of the Zcash network; node broadcasting or accepting blocks that other nodes reject.
  • Logs: Zebra node logs showing acceptance of blocks containing transactions with expired expiry heights or violated lock times; log entries indicating contextual verification passing for transactions that should be invalid at the committed block height.
  • Process/State: Node's reported chain tip diverging from the canonical Zcash chain tip as reported by other nodes or block explorers; node failing to sync or rejecting new valid blocks from the majority chain after the split.
  • Mempool: Presence of transactions in the mempool with expiry heights at or below the current chain tip, which should have been evicted (GitHub Advisory).

Mitigation and workarounds

Operators should immediately upgrade to the patched versions: zebra-consensus 5.0.2 or later, and zebrad 4.3.1 or later. There are no known configuration-based workarounds — the advisory explicitly states that immediate upgrade is the only way to ensure the node remains on the correct consensus path (GitHub Advisory, Zebra Advisory). The fix removes the risky performance optimization from the transaction verification cache entirely, ensuring all transactions are fully re-validated against the current block height (Zcash Foundation Blog).

Community reactions

The Zcash Foundation published a blog post alongside the release of Zebra 4.3.1 highlighting the critical security fixes included in the release (Zcash Foundation Blog). The advisory credits two independent researchers — @sangsoo-osec (who identified the lock time issue) and @shieldedonly (who identified additional aspects of the transaction validation flaw) — for thorough advisory submissions that led to the discovery (GitHub Advisory). No significant broader media coverage or social media discussion has been identified beyond the official advisory channels.

Additional resources


SourceThis report was generated using AI

Related Rust vulnerabilities:

CVE ID

Severity

Score

Technologies

Component name

CISA KEV exploit

Has fix

Published date

RUSTSEC-2026-0236HIGH7.5
  • Rust logoRust
  • viperjs
NoYesAug 06, 2026
RUSTSEC-2026-0232HIGH7.5
  • Rust logoRust
  • nostr-relay-pool
NoYesAug 01, 2026
RUSTSEC-2026-0231HIGH7.5
  • Rust logoRust
  • nostr-relay-pool
NoYesAug 01, 2026
RUSTSEC-2026-0230HIGH7.5
  • Rust logoRust
  • nostr
NoYesAug 01, 2026
CVE-2026-68930MEDIUM6.5
  • Rust logoRust
  • russh
NoYesAug 03, 2026

Free Vulnerability Assessment

Benchmark your Cloud Security Posture

Evaluate your cloud security practices across 9 security domains to benchmark your risk level and identify gaps in your defenses.

Request assessment

Get a personalized demo

Ready to see Wiz in action?

"Best User Experience I have ever seen, provides full visibility to cloud workloads."
David EstlickCISO
"Wiz provides a single pane of glass to see what is going on in our cloud environments."
Adam FletcherChief Security Officer
"We know that if Wiz identifies something as critical, it actually is."
Greg PoniatowskiHead of Threat and Vulnerability Management