Description

Zebra before 6.1.0 contains an incomplete cleanup vulnerability in the state write task that allows remote unauthenticated peers to stall node synchronization by poisoning parent_error_map. Attackers can deliver a coinbase-malleated block sharing a canonical block's hash before it propagates, causing the next canonical block to be rejected and stalling the node for roughly 2,000 blocks.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-10-02T12:17:13.030Z",
  "pubdate": "2026-10-02T12:17:13.030Z",
  "executiveSummary": "Zebra versions prior to 6.1.0 are susceptible to an incomplete cleanup vulnerability within the state write task, leading to a significant denial-of-service condition.\nThe vulnerability allows remote, unauthenticated attackers to intentionally stall node synchronization by poisoning the parent_error_map data structure.\nBy delivering a coinbase-malleated block that shares a canonical block's hash prior to the canonical block's propagation, the attacker triggers an error state that rejects the legitimate canonical block.\nThis action effectively forces the affected node to halt synchronization for approximately 2,000 blocks, severely impacting the availability and liveness of the node within the network.\nThe risk implication is high for network participants, as it enables trivial network disruption without requiring prior authentication or elevated privileges. The exploit relies on precise timing of block delivery to weaponize the state write task's failure to properly manage cached error states.",
  "technicalDetails": "The vulnerability resides within the state write task component of Zebra, specifically concerning the management of the parent_error_map. The root cause is an incomplete cleanup process during block validation where incorrect or malicious error states are not properly purged from the cache when dealing with coinbase-malleated blocks.\nThe attack vector involves a remote, unauthenticated peer injecting a specially crafted, coinbase-malleated block into the node. This block is designed to share the hash of a future or upcoming canonical block. Because the node processes the malleated block, it populates the parent_error_map with an entry indicating that the specific hash is associated with an error state.\nWhen the legitimate canonical block arrives at the node, the state write task checks the parent_error_map to verify if the block has already been marked as invalid. Due to the incomplete cleanup, the previous entry from the malleated block persists. The node erroneously identifies the canonical block as invalid based on the poisoned map, leading to a rejection of the valid block.\nThis triggers a persistent synchronization stall. Because the error map entry remains cached, subsequent validation attempts for that block hash continue to fail, effectively locking the node out of the chain tip progression. The state effectively persists for approximately 2,000 blocks until the error condition clears or the cache is flushed via alternative mechanisms.\nThis exploitation technique does not require elevated privileges or pre-existing trust, as the node automatically processes incoming block data as part of its standard synchronization protocols. The impact is a total loss of node synchronization capability for the duration of the stall, which poses a significant threat to network decentralization and node availability. The vulnerability highlights a failure in isolation between potentially untrusted, malleated block data and the persistent state used for consensus-critical validation logic."
}