EUVD-2026-91432
GHSA-xx63-6p6j-3wv7
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessConnect as unauthenticated P2P peer
-
DeliverySend contextually invalid block reusing honest header hash
-
ExploitRejected hash left in SentHashes (incomplete cleanup)
-
ExecutionRequest::KnownBlock skips the valid block
-
ImpactNode stalls behind chain tip
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Incomplete cleanup
|
| Exploitation Conditions | Exploitation requires the attacker to establish an unauthenticated peer connection on Zebra's P2P (block-sync) interface and send a contextually invalid block that shares the header hash of an honest block; this is feasible against default configurations because peer connections are inherent to node operation (AV:N/PR:N/UI:N). The key LIMITING factor is scope of impact: the attack only delays block download and keeps the node behind the tip (VA:L) for nodes actively syncing - it does not crash the node, disclose data, or alter the chain, and it affects only the targeted node(s) the attacker peers with. Affected: Zcash Foundation Zebra at all versions below 6.2.1. |
| Impact | This is a genuine but moderate-priority availability/liveness issue, not a critical flaw. The supplied CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N, score 6.9) shows a remotely reachable, low-complexity, unauthenticated attack - easy to launch against any peer-exposed node - but the impact is strictly VA:L (partial availability) with VC:N/VI:N, meaning no confidentiality or integrity loss and no node crash; the effect is that a targeted node stalls behind the chain tip. No EPSS score was provided, the CVE is NOT in CISA KEV, and no public POC was referenced, so there is no evidence of active or automated exploitation at this time. Note a conflict in the metadata: the 'Information Disclosure' tag directly contradicts the CVSS (VC:N) and the CWE-459 incomplete-cleanup root cause - this is a denial-of-service/consensus-liveness bug, not an information-disclosure one, so the tag should not be used for triage. Overall: patchable (6.2.1 available), easy to trigger, low blast radius - prioritize routine patching for exposed nodes rather than emergency response. |
| Exploit ScenarioDerived | An attacker connects to a target Zebra node as an unauthenticated peer and sends a contextually invalid block crafted to reuse the header hash of a legitimate block. Because the rejected hash is not removed from SentHashes (incomplete cleanup), Request::KnownBlock later skips the honest block, so the node never downloads the valid block and remains stuck behind the chain tip. No public exploit identified at time of analysis. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Oct 02, 2026
Block download denial of service in the Zcash Foundation's Zebra node before 6.2.1 lets any unauthenticated peer on the node's P2P block-sync interface stall synchronization and keep the node behind the chain tip by sending a contextually invalid block whose header hash matches that of an honest block, causing the honest block to be skipped. The root cause is an incomplete-cleanup defect (CWE-459) in which rejected hashes linger in Zebra's SentHashes tracking, so Request::KnownBlock keeps treating the legitimate block as already known. The reporting CNA assigns CVSS:4.0 base 6.9, while the independent assessment rates it CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L - a genuine but moderate availability/liveness issue rather than a critical flaw, since it causes no crash, no data disclosure, and no chain alteration; no public exploit code exists and there is no confirmed active exploitation (not listed in CISA KEV) at time of analysis. Only nodes actively catching up are affected - a fully synced node that is not syncing onward is not impacted.
RemediationAI
Vendor-released patch: upgrade to Zebra 6.2.1, the first release outside the affected "<6.2.1" range, which corrects the incomplete cleanup of SentHashes so that rejected hashes no longer suppress the download of honest blocks. Follow the Zcash Foundation advisory at https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-x93j-mj2f-q338 for the authoritative upgrade guidance, and the VulnCheck advisory at https://www.vulncheck.com/advisories/zebra-before-6.2.1-block-download-denial-of-service-via-knownblock-senthashes-lockout for reproduction and detection context. If upgrading cannot be done immediately, compensating controls are limited because the attack rides on the normal P2P block-sync path: restrict inbound peer connections to a trusted set of peers (e.g., disable automatic inbound peer acceptance and rely on explicitly configured, trusted addnode/seed peers) so that arbitrary unauthenticated peers cannot inject the poisoned block - accepting the trade-off of reduced peer diversity, slower sync, and greater exposure if those trusted peers are unavailable; and monitor for nodes that persistently stall behind the chain tip, treating a restart plus a re-sync from trusted peers as a temporary recovery measure rather than a fix, since the same poisoning can recur once an attacker reconnects. Neither workaround removes the underlying incomplete-cleanup defect, so patching to 6.2.1 remains the only complete remediation; no details on backport availability for earlier release lines are provided in the source data.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 1 package in euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Zebra is the Zcash Foundation's Rust implementation of a Zcash full node; its block-sync logic runs over the same peer-to-peer protocol surface as other Zcash/Bitcoin-lineage nodes, where peers announce block headers and bodies and the node tracks which hashes it has requested or deemed unusable. The flaw belongs to CWE-459 (Incomplete Cleanup): when a block is rejected, its hash is not fully purged from the SentHashes state, which backs the Request::KnownBlock lookup used to decide whether a given block still needs to be downloaded. Because a block's identity in this lookup is keyed on the header hash, an attacker can present a contextually invalid block - one that is structurally and header-hash-consistent with an honest block but fails contextual validation - and thereby poison the tracking state so that the honest block sharing that header hash is treated as already known and skipped. The result is that the node's sync loop keeps the honest chain segment out of reach and remains behind the tip. The vulnerability is reachable by any peer that can connect to the node's block-sync interface (CVSS vector shows PR:N and UI:N, i.e., unauthenticated and requiring no user interaction); there is no memory-safety, authentication, or cryptographic-bypass component, and the CPE cpe:2.3:a:zcashfoundation:zebra:*:*:*:*:*:*:*:* confirms all pre-6.2.1 builds are in scope, matching EUVD-2026-91432's "zebra 0 <6.2.1" range.
Know when Zebra gets its next vulnerability
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:N
Unauthenticated network peer with low complexity (AV:N/AC:L/PR:N/UI:N); impact confined to block-sync liveness so A:L only, with no confidentiality or integrity effect.
Primary rating from Vendor (VulnCheck).
CVSS VectorVendor: VulnCheck
Lifecycle Timeline
1DescriptionCVE.org
Zebra before 6.2.1 contains an incomplete cleanup vulnerability that allows unauthenticated peers to block downloading of valid blocks by leaving rejected hashes in SentHashes. Attackers can send a contextually invalid block sharing an honest block's header hash, causing Request::KnownBlock to skip the honest block and keep nodes behind the tip.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Remote denial-of-service in Zebra (Zcash node implementation) versions prior to 4.4.0 allows unauthenticated attackers t
Motorola FX9500 devices allow remote attackers to conduct absolute path traversal attacks, as demonstrated by PL/SQL Ser
An issue was discovered on Zebra (formerly Motorola Solutions) Fixed RFID Reader FX9500 devices. Rated critical severity
Remote, unauthenticated denial of service in Zcash Foundation's Zebra full node: versions 6.4.0 through 6.4.1 abort when
Unauthenticated denial of service in Zebra (Zcash Foundation's full node implementation) before 6.0.0 allows remote peer
Remote unauthenticated attackers can cause a consensus divergence in Zcash Zebra nodes (zebrad 4.5.0 and zebra-script 7.
Zcash Foundation's Zebra full node (zebrad) before 6.2.1 can be stalled in block verification by any unauthenticated pee
Block-sync denial of service in Zebra (zebrad), the Rust implementation of a Zcash full node, affects all versions befor
Consensus divergence in Zebra Zcash nodes before 4.4.0 allows unauthenticated remote attackers to craft V5 transparent t
Zcash Zebra nodes running zebrad 4.4.0 or zebra-script 6.0.0 incorrectly accept V5 transparent transactions in which a S
Denial of service in the Zcash Foundation's Zebra full node before 6.1.0 lets remote unauthenticated peers stall node sy
Denial of service in the Zcash Foundation's Zebra full node implementation before 6.1.0 allows an unauthenticated remote
Exploit-DB