CVE-2026-104422 in Zebra
Summary
by MITRE • 10/02/2026
The block sync download path in Zebra (zebrad) before 6.3.0 reads a block's height from its unvalidated coinbase scriptSig and drops blocks that appear too far behind the tip before consensus validation, without penalizing the supplying peer. Because V5 transaction IDs exclude the scriptSig, a malicious peer can repeatedly serve a canonical block whose coinbase claims height 1 while keeping the requested hash, delaying the node's discovery of the newest block.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in Zebra versions prior to 6.3.0 represents a critical flaw in the initial synchronization logic of the blockchain client, specifically within the block sync download path. This issue stems from an improper validation mechanism where the software relies on untrusted data sources for determining consensus state before performing rigorous cryptographic checks. Specifically, zebrad reads the height information directly from the coinbase scriptSig field of a received block header or transaction without first validating that this value is consistent with the actual blockchain history or the block's position in the chain. This design choice creates a significant window of opportunity for malicious actors to manipulate the synchronization process by providing blocks with fabricated metadata, thereby disrupting the node's ability to accurately track its progress toward the network tip.
The technical core of this flaw lies in how Zebra handles incoming blocks during the initial sync phase. When a peer supplies a block hash that the local node does not yet possess, zebrad attempts to fetch and process it. However, before executing full consensus validation rules which would verify the proof-of-work and structural integrity against previous blocks, the software checks if the claimed height of the incoming block is too far behind the current tip. If the coinbase scriptSig indicates a low height value, such as 1, while the node's tip is significantly higher, zebrad incorrectly assumes this block is stale or irrelevant. Consequently, it discards the block and fails to penalize the peer that supplied it. This behavior violates standard consensus rules which typically require nodes to reject invalid blocks from peers but also incentivizes honest participation by rewarding valid chain progress; here, the node actively ignores potentially useful data due to a premature heuristic check based on unvalidated input.
The exploitation of this vulnerability allows for a denial-of-service attack against individual network participants through block withholding and synchronization delay techniques. Because V5 transaction IDs in Zcash exclude the scriptSig from their calculation, an attacker can craft a canonical-looking block where the coinbase claims to be at height 1 while maintaining all other cryptographic properties required by the hash function. By repeatedly serving this specific malformed block to multiple nodes or persistently offering it to a single node, the malicious peer forces zebrad to continuously reject valid chain segments that appear deceptively old. This results in a significant delay in the victim's discovery of the newest blocks on the network, effectively stalling their synchronization progress without triggering any anti-spam penalties against the attacker.
From an industry standard perspective, this vulnerability aligns with CWE-20 Improper Input Validation and CWE-754: Improper Check for Unusual or Exceptional Conditions. The failure to validate the source of critical metadata before using it for control flow decisions is a classic example of input validation bypass. Furthermore, in the context of the MITRE ATT&CK framework, this behavior facilitates techniques associated with Resource Hijacking and Defense Evasion by slowing down node synchronization, which can be leveraged to isolate nodes from real-time network updates or facilitate double-spending attempts if combined with other attacks like eclipse attacks. The lack of peer penalization exacerbates the impact, as it removes a key deterrent against malicious behavior in decentralized networks that rely on economic incentives for security.
Mitigating this vulnerability requires immediate software updates to version 6.3.0 or later, where the synchronization logic has been corrected to ensure that block height is derived from validated consensus data rather than untrusted script fields during the initial fetch phase. Network operators should also consider implementing stricter peer scoring mechanisms that penalize nodes for supplying blocks with inconsistent metadata, even if those blocks are ultimately discarded due to other validation failures. Additionally, developers of similar blockchain clients should review their sync paths to ensure no critical state decisions are made based on unvalidated transaction fields before full consensus rules are applied, thereby preventing similar manipulation vectors in the future.