Zebra state: Zebra has block suppression via NU5 same-header body poisoning of sent-hash cache (CVE-2026-52736)
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.
AI Analysis
Technical Summary
Zebra's zebrad client up to and including v4.4.1 is vulnerable to a block suppression attack via a poisoned block body sharing a header hash with a valid canonical block. The node caches the block hash in non_finalized_block_write_sent_hashes before validation. If validation fails due to a poisoned block body (crafted by mutating the coinbase scriptSig extra-data under ZIP-244 malleability), the hash remains cached. When the valid block arrives, it is rejected as a duplicate, causing the node to stall at that height. This can be exploited by a remote unauthenticated P2P peer who wins the propagation race. The vulnerability also affects chain pruning scenarios leaving stale hashes in the cache. The issue is fixed in Zebra 4.4.2 by removing stale hashes on failed writes. There is no full configuration workaround; node restart clears the cache and allows recovery.
Potential Impact
A remote unauthenticated peer can cause a Zebra node to permanently stall at a specific block height by delivering a poisoned block body that causes the node to cache a block hash erroneously. This prevents the node from accepting the valid canonical block, causing it to diverge from the network tip. Downstream services relying on the node will see a stalled chain. The attack requires winning a propagation race and can be sustained to keep the node behind the network indefinitely. Recovery requires node restart or a rare chain reorganization. This impacts network reliability and data freshness for affected nodes.
Mitigation Recommendations
An official patch is available in Zebra version 4.4.2 that fixes this issue by removing stale entries from the sent-hash cache on failed validation. Users should upgrade to Zebra 4.4.2 or later. There is no complete configuration workaround; reducing inbound peer count can reduce but not eliminate risk. Restarting the node clears the in-memory cache and allows recovery if the node is stalled. Operators should apply the patch promptly to prevent potential denial of service via block suppression.
Zebra state: Zebra has block suppression via NU5 same-header body poisoning of sent-hash cache (CVE-2026-52736)
Description
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.
CVSS v4.0
Affected software
Run on your own infrastructure? Check whether these packages are installed with threat-finder — our free open-source scanner.
Weaknesses
AI-Powered Analysis
Machine-generated threat intelligence
Technical Analysis
Zebra's zebrad client up to and including v4.4.1 is vulnerable to a block suppression attack via a poisoned block body sharing a header hash with a valid canonical block. The node caches the block hash in non_finalized_block_write_sent_hashes before validation. If validation fails due to a poisoned block body (crafted by mutating the coinbase scriptSig extra-data under ZIP-244 malleability), the hash remains cached. When the valid block arrives, it is rejected as a duplicate, causing the node to stall at that height. This can be exploited by a remote unauthenticated P2P peer who wins the propagation race. The vulnerability also affects chain pruning scenarios leaving stale hashes in the cache. The issue is fixed in Zebra 4.4.2 by removing stale hashes on failed writes. There is no full configuration workaround; node restart clears the cache and allows recovery.
Potential Impact
A remote unauthenticated peer can cause a Zebra node to permanently stall at a specific block height by delivering a poisoned block body that causes the node to cache a block hash erroneously. This prevents the node from accepting the valid canonical block, causing it to diverge from the network tip. Downstream services relying on the node will see a stalled chain. The attack requires winning a propagation race and can be sustained to keep the node behind the network indefinitely. Recovery requires node restart or a rare chain reorganization. This impacts network reliability and data freshness for affected nodes.
Mitigation Recommendations
An official patch is available in Zebra version 4.4.2 that fixes this issue by removing stale entries from the sent-hash cache on failed validation. Users should upgrade to Zebra 4.4.2 or later. There is no complete configuration workaround; reducing inbound peer count can reduce but not eliminate risk. Restarting the node clears the in-memory cache and allows recovery if the node is stalled. Operators should apply the patch promptly to prevent potential denial of service via block suppression.
Technical Details
- Gcve Source
- db.gcve.eu
- Osv Id
- GHSA-4m69-67m6-prqp
- Osv Schema Version
- 1.4.0
- Aliases
- ["CVE-2026-52736"]
- Ecosystems
- ["crates.io"]
- Database Specific Severity
- HIGH
- Cvss Version
- 4.0
Threat ID: 6a46ecb727e9c7971943ca13
Added to database: 07/02/2026, 22:56:55 UTC
Last enriched: 08/19/2026, 11:13:51 UTC
Last updated: 09/14/2026, 22:01:35 UTC
Views: 499
Community Reviews
0 reviewsCrowdsource mitigation strategies, share intel context, and vote on the most helpful responses. Sign in to add your voice and help keep defenders ahead.
Want to contribute mitigation steps or threat intel context? Sign in or create an account to join the community discussion.
Actions
Updates to AI analysis require Pro Console access. Upgrade inside Console → Billing.
Need more coverage?
Upgrade to Pro Console for AI refresh and higher limits.
For incident response and remediation, OffSeq services can help resolve threats faster.
Latest Threats
Check if your credentials are on the dark web
Instant breach scanning across billions of leaked records. Free tier available.