Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-10-02T12:17:12.283Z",
  "pubdate": "2026-10-02T12:17:12.283Z",
  "executiveSummary": "This vulnerability in zebrad versions prior to 6.3.0 involves a logic flaw in the block synchronization path, specifically regarding how block heights are parsed from unvalidated coinbase scriptSig data.\nA remote attacker can perform a Denial-of-Service (DoS) attack by serving blocks with spoofed, low-height coinbase metadata. Because the node processes this unvalidated information before full consensus verification, it incorrectly identifies valid blocks as being too far behind the chain tip.\nThe vulnerability allows an unauthenticated, network-adjacent attacker to prevent a node from discovering the latest blocks, effectively stalling synchronization and causing network partition or degradation.\nThe core issue stems from an over-reliance on untrusted transaction data to make synchronization routing decisions. Since V5 transaction IDs do not include the scriptSig, the malicious peer can bypass integrity checks while manipulating the node's view of the blockchain height. The impact is significant for network liveness, as affected nodes fail to maintain an accurate consensus state without triggering standard peer penalization mechanisms.",
  "technicalDetails": "The vulnerability resides within the block synchronization logic of the zebrad daemon. During the block download process, the implementation attempts to verify block height by inspecting the coinbase transaction's scriptSig field. In the Zcash protocol, the coinbase transaction contains metadata, and historically, some implementations relied on the scriptSig to determine the block height for early filtering.\nThe root cause is the reliance on unvalidated data from an untrusted peer to make synchronization path decisions. When zebrad receives a block, it reads the height directly from the unvalidated coinbase scriptSig before the block has undergone full consensus validation or context-dependent checks. If the parsed height appears to be significantly behind the current chain tip, the node drops the block.\nThe exploitation vector leverages the structure of V5 transactions. Because V5 transaction identifiers (txids) do not include the coinbase scriptSig, an attacker can construct a payload where the block hash remains valid and canonical, but the internal scriptSig is modified to report a height of 1. By repeatedly serving such blocks to a target zebrad node, the attacker forces the node to ignore legitimate synchronization data.\nThe attack flow is as follows: 1) The zebrad node requests a block hash from a malicious peer. 2) The peer provides the legitimate block content but ensures the coinbase scriptSig indicates an erroneously low block height. 3) The zebrad daemon parses the height from the scriptSig before performing full cryptographic verification or consensus rule enforcement. 4) The daemon compares the spoofed height to the current chain tip; finding it too low, it discards the block as irrelevant. 5) Crucially, the system does not apply peer-based reputation penalties, as the block is discarded during the early validation phase rather than due to a detected protocol violation. 6) This prevents the node from successfully syncing the latest block headers and data, effectively stalling the node's progression.\nThis vulnerability exposes the node to persistent synchronization interference. No authentication is required for a peer to initiate this request-response cycle, and the network exposure is inherent to the P2P nature of the zebrad synchronization protocol. The post-exploitation impact is a targeted DoS, preventing the affected node from participating in the network consensus."
}