CVE-2026-52736: Zebra Zcash Node DoS Vulnerability

CVE-2026-52736 Overview

CVE-2026-52736 affects Zebra, a Zcash node implementation written in Rust and maintained by the Zcash Foundation. A remote unauthenticated peer-to-peer (P2P) peer can stall a Zebra node by racing an invalid block body against the valid canonical body for the same block header hash. The flaw resides in zebra-state/src/service.rs within the queue_and_commit_to_non_finalized_state function, which incompletely cleaned up state when a poisoned block body failed commitment validation. The bug is tracked as an incomplete cleanup weakness [CWE-459] and is resolved in Zebra version 4.5.0.

Critical Impact
An unauthenticated network attacker can force a Zebra node to stall one block behind the canonical chain until restart or reorganization, degrading Zcash network consensus participation.

Affected Products

Zebra Zcash node versions prior to 4.5.0
Zcash Foundation zebra-state crate
Nodes exposing the Zcash P2P network interface

Discovery Timeline

2026-08-18 - CVE-2026-52736 published to NVD
2026-08-18 - Last updated in NVD database

Technical Details for CVE-2026-52736

Vulnerability Analysis

Zebra participates in the Zcash P2P network and downloads block bodies from peers to extend its local chain state. The vulnerability stems from how the non-finalized state machine tracks in-flight block writes. When a peer supplied a block body matching an expected header hash, Zebra recorded the hash in the non_finalized_block_write_sent_hashes set before contextual validation completed. If the body later failed commitment validation, the recorded hash was not removed. When the honest body for the same header hash arrived from another peer, the duplicate-suppression path in KnownBlock::WriteChannel silently discarded it. The node then stalled one height behind the canonical tip until an operator restart or a chain reorganization.

Root Cause

The root cause is incomplete state cleanup on a failed asynchronous write task. Zcash Improvement Proposal 244 (ZIP-244) permits mutation of the coinbase scriptSig authentication data while preserving transaction identifiers, the merkle root, and the block header hash. An attacker can therefore construct a block body that shares the canonical hash but fails later commitment checks. Because Zebra treated the cached hash as authoritative regardless of write outcome, the failure path left orphan state in memory.

Attack Vector

Any unauthenticated remote peer connected over the Zcash P2P protocol can trigger the stall by racing a malformed body to the target node before the honest body arrives. No credentials, user interaction, or local access are required. The attack targets integrity of chain progression rather than confidentiality or availability of the process itself.

text

// Patch metadata from release v4.5.0 (#10647)
[[package]]
 name = "zebra-chain"
-version = "7.0.0"
+version = "8.0.0"
 dependencies = [
  "bech32",
  "bitflags 2.11.1",

Source: Zebra commit 1440b43

Detection Methods for CVE-2026-52736

Indicators of Compromise

Zebra node reports a best chain tip height that lags peers by exactly one block for extended periods without natural reorganization.
Repeated KnownBlock::WriteChannel duplicate-suppression log entries for the same block hash after a validation rejection.
P2P peer supplying a block body whose coinbase scriptSig differs from the canonical body but whose header hash matches.

Detection Strategies

Monitor zebrad logs for commitment validation failures immediately followed by suppressed writes for the same block hash.
Compare the local chain tip height against multiple independent Zcash block explorers or trusted peers on a scheduled interval.
Alert when the Zebra process remains at a stable non-tip height while peer connections and message traffic remain healthy.

Monitoring Recommendations

Instrument metrics exposed by zebrad (Prometheus endpoint) to track best_chain_height deltas versus peer-reported heights.
Capture P2P block message telemetry at the network edge for post-incident correlation of malicious peer sources.
Forward node logs to a centralized data lake or SIEM to preserve evidence of stall events across restarts.

How to Mitigate CVE-2026-52736

Immediate Actions Required

Upgrade every Zebra deployment to version 4.5.0 or later, which corrects the cleanup logic in queue_and_commit_to_non_finalized_state.
Restart any Zebra node currently stalled behind the canonical tip to clear cached hashes from non_finalized_block_write_sent_hashes.
Review inbound P2P peer connections and disconnect peers that repeatedly submit bodies failing commitment validation.

Patch Information

The fix ships in Zebra v4.5.0, released by the Zcash Foundation. Reference the GitHub Security Advisory GHSA-4m69-67m6-prqp, the v4.5.0 release notes, and the remediation commit 1440b43. The patch ensures that hashes recorded in the sent-hashes set are removed when the associated write task rejects the body.

Workarounds

Restrict inbound P2P connections to a curated allowlist of trusted Zcash peers until the upgrade is applied.
Automate health checks that restart zebrad when the local tip lags an independent reference by more than one block for a defined interval.
Run redundant Zebra instances behind an application-level chain-tip verifier so downstream consumers fail over from a stalled node.

bash

# Upgrade Zebra to the patched release
git clone https://github.com/ZcashFoundation/zebra.git
cd zebra
git checkout v4.5.0
cargo build --release --package zebrad

# Verify the running version reports 4.5.0 or later
./target/release/zebrad --version