EUVD-2026-61163
GHSA-gvjc-3w7c-92jx
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L
Network P2P attack requiring no authentication (AV:N, PR:N, AC:L); impact is purely availability degradation with no crash, data loss, or integrity effect (C:N/I:N/A:L).
Primary rating from Vendor (https://github.com/ZcashFoundation/zebra).
CVSS VectorVendor: https://github.com/ZcashFoundation/zebra
Lifecycle Timeline
1DescriptionCVE.org
Am I affected
You are affected if:
- You run
zebradup to and includingv4.4.1. - Your node accepts inbound P2P connections and is syncing or catching up to the chain tip.
Summary
A malicious peer can answer Zebra's outbound getblocks/FindBlocks request with a small two-hash inventory, then serve a syntactically valid block whose coinbase height is far above the victim's local tip. The AboveLookaheadHeightLimit error in the sync download pipeline triggers a global sync restart rather than being scoped to the offending peer. The peer is never scored or disconnected because the error type does not carry the advertiser address.
On mainnet, each successful cycle imposes a 67-second sync restart delay. All in-flight downloads from honest peers are cancelled on each restart.
Details
The bug is the interaction of three layers:
- The syncer promotes unvalidated
FindBlockspeer responses into concrete download schedules without checking that the advertised hashes are plausible chain extensions. - When a downloaded block's coinbase height exceeds
tip + VERIFICATION_PIPELINE_DROP_LIMIT, the sync downloader returnsBlockDownloadVerifyError::AboveLookaheadHeightLimit. This error variant carries only the block height and hash, not the advertiser peer address. - The sync error handler in
handle_block_responseonly sends misbehaviour scores forBlockDownloadVerifyError::Invaliderrors that carry anadvertiser_addrand have a nonzeromisbehavior_score().AboveLookaheadHeightLimitfalls through to the default restart-worthy path, cancelling all in-flight downloads and waiting 67 seconds before restarting sync.
The attacker needs only an unauthenticated P2P connection (post-handshake), a tiny payload (one two-hash inv message plus one small block per cycle), and no mining capability, funds, or valid chain data. The peer is never penalised, so the attack is repeatable indefinitely.
Additionally, several other pre-consensus sync-layer errors had zero misbehaviour scores even when peer-attributed. Contextual validation failures (InvalidDifficultyThreshold, TimeTooEarly, TimeTooLate, NonSequentialBlock) and locktime failures from block-serving peers all scored zero, allowing repeated abuse without penalty.
Patches
Patched in Zebra 4.4.2. The fix:
- Carries
advertiser_addrthroughAboveLookaheadHeightLimitandInvalidHeighterror variants. - Makes above-lookahead and invalid-height failures peer-local (the block is dropped and the peer is banned with score 100) rather than triggering a global sync restart.
- Expands
misbehavior_score()acrossBlockError,VerifyBlockError, andCommitBlockErrorto cover contextual validation failures that previously scored zero.
Workarounds
No configuration-level workaround is available. The attack is mitigated by having a diverse honest peer set, but cannot be prevented while the vulnerable code is running.
Impact
A single unauthenticated peer can repeatedly stall a syncing Zebra node by forcing 67-second global sync restart cycles. All unrelated in-flight downloads are cancelled on each restart. The node does not crash and no state is corrupted, but sync progress is significantly degraded for the duration of the attack.
Credit
Reported by @ipwning.
AnalysisAI
Repeated sync-stalling via a crafted P2P block response in Zebra (zebrad) v4.4.1 and earlier allows any unauthenticated peer to indefinitely delay a syncing node's chain catch-up by forcing 67-second global sync restart cycles. The root cause is that the AboveLookaheadHeightLimit error variant in the sync download pipeline does not carry the advertiser's peer address, so the offending peer is never scored or disconnected, and the restart cancels all in-flight downloads from honest peers on every cycle. No public exploit has been identified at time of analysis, but the vendor advisory confirms the attack requires no authentication, mining capability, or valid chain data - only a standard post-handshake P2P connection.
Technical ContextAI
Zebra (zebrad) is the Zcash Foundation's Rust-based full node implementation for the Zcash blockchain, comprising the pkg:rust/zebrad binary and the pkg:rust/zebra-consensus library. The vulnerability is rooted in CWE-345 (Insufficient Verification of Data Authenticity): the sync pipeline's FindBlocks/getblocks response handler promotes unvalidated peer-advertised block hashes directly into concrete download schedules without first verifying that the advertised hashes represent plausible chain extensions relative to the local tip. When a downloaded block's coinbase height exceeds tip + VERIFICATION_PIPELINE_DROP_LIMIT, the downloader returns BlockDownloadVerifyError::AboveLookaheadHeightLimit carrying only the block height and hash - not the originating peer address. The misbehavior scoring system in handle_block_response only penalizes errors of type BlockDownloadVerifyError::Invalid that carry an advertiser_addr and return a nonzero misbehavior_score(); AboveLookaheadHeightLimit falls through to the global restart path. A secondary issue is that several other pre-consensus sync errors (InvalidDifficultyThreshold, TimeTooEarly, TimeTooLate, NonSequentialBlock, locktime failures) also carried zero misbehavior scores even when peer-attributed, enabling repeated abuse without penalty.
RemediationAI
Upgrade to Zebra v4.4.2, the vendor-released patched version confirmed in the Zcash Foundation security advisory (https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-gvjc-3w7c-92jx). The fix carries advertiser_addr through AboveLookaheadHeightLimit and InvalidHeight error variants, converts these failures from global sync restarts to peer-local bans (score 100, peer dropped), and expands misbehavior_score() across BlockError, VerifyBlockError, and CommitBlockError to cover contextual validation failures that previously scored zero. No configuration-level workaround exists per the vendor. As a partial, non-preventive mitigation, operators can maximize peer diversity by connecting to multiple well-known honest Zcash nodes, which reduces the statistical window in which the attacker's peer is selected for block downloads; however, this does not prevent the attack while vulnerable code is running. Rate-limiting inbound P2P connections at the network perimeter can reduce the attacker's ability to maintain persistent connections but cannot eliminate the vulnerability since even a single connection suffices.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today