CVE-2026-52737: Zebra consensus · Zebra has sync restart poisoning from single unauthenticated peer via above-lookahead block
Affects zebra-consensusSource GCVE Database
Not known to be exploited · CVSS 5.3 Medium : upgrade to 7.0.0 when convenient.
Data as of 29 Oct 2026, 19:04 UTC
- EPSS
- 0.2% chance of exploitation in 30 days – higher than 18% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 7.0.0, 4.5.0
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:LExploitation evidence
Disclosed: evidence found.
CVE published 18 Aug 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponized: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 29 Oct 2026.
What to do
Upgrade zebra-consensus to 7.0.0; zebrad to 4.5.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| crates.iozebra-consensus | Affected
| Fixed in
|
| crates.iozebrad | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
A patch is available in Zebra version 4.4.2 that addresses this vulnerability by adding peer-specific error handling and banning misbehaving peers to prevent global sync restarts. Users should upgrade to Zebra 4.4.2 or later. There are no configuration-level workarounds; mitigation depends on running the patched software. Maintaining a diverse set of honest peers may reduce attack impact but does not prevent it.
Description
ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, a malicious unauthenticated P2P peer can answer Zebra's outbound getblocks or FindBlocks request with a small two-hash inventory and then serve a syntactically valid block whose coinbase height is far above the local chain tip. In zebrad/src/components/sync/downloads.rs, BlockDownloadVerifyError::AboveLookaheadHeightLimit originally carried only the block height and hash, so handle_block_response could not attribute the failure to the advertising peer. The error then reached the restart-worthy default path in zebrad/src/components/sync.rs, cancelling all in-flight downloads from honest peers and imposing a 67-second sync restart delay on mainnet. Because the peer was neither scored nor disconnected, the peer could repeat the cycle indefinitely with minimal bandwidth and significantly degrade synchronization without corrupting state. This issue is fixed in version 4.5.0.