CVE-2026-104423 in Zebra
Summary
by MITRE • 10/02/2026
Zebra (zebrad) before 6.2.1 contains an asymmetric resource consumption vulnerability that allows unauthenticated peers to stall block verification by pushing V6 mempool transactions with invalid Halo2 proofs. Attackers can flood the shared unprioritized Halo2 verification queue with zero-fee transactions carrying zero-filled Orchard and Ironwood proofs, causing nodes to fall behind the chain tip.
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.2.1 represents a significant denial-of-service risk stemming from an asymmetric resource consumption flaw within the node's transaction verification pipeline. This issue specifically targets the handling of V6 mempool transactions that include invalid Halo2 cryptographic proofs. In blockchain networks utilizing zero-knowledge proof systems like Halo2, verifying these proofs is computationally intensive and requires substantial processing power. The core technical flaw lies in how Zebra processes incoming transactions from unauthenticated peers before they are fully validated or filtered by consensus rules. Attackers can exploit this window of opportunity by flooding the shared unprioritized verification queue with a high volume of zero-fee transactions that contain malformed Halo2 proofs, specifically those featuring zero-filled Orchard and Ironwood proof structures. Because these proofs are invalid yet structurally present, the node is forced to engage in expensive cryptographic computations to attempt their validation, only to fail after consuming significant CPU cycles and memory resources.
This asymmetric attack vector allows malicious actors to stall block verification processes effectively without needing any authentication credentials or network privileges beyond basic connectivity. The operational impact of this vulnerability is severe for network participants, as the excessive load on the Halo2 verification queue can cause nodes to fall behind the chain tip. When a node cannot keep up with the rate of incoming transactions due to resource exhaustion from processing invalid proofs, its synchronization state degrades, potentially leading to temporary desynchronization or complete service unavailability depending on the scale and persistence of the attack. This degradation undermines the reliability and availability of the network for legitimate users who depend on timely block propagation and transaction confirmation. The vulnerability highlights a critical gap in input validation strategies where computationally expensive operations are not sufficiently gated by preliminary checks that could reject obviously malformed or zero-filled proof structures before they enter the main verification queue.
From a classification perspective, this flaw aligns with CWE-400, which describes uncontrolled resource consumption, and more specifically relates to CWE-787, out-of-bounds write if memory corruption occurs during processing, though primarily it is an issue of inefficient resource management leading to denial of service. In the context of the MITRE ATT&CK framework for adversarial tactics against blockchain systems, this behavior corresponds to techniques aimed at disrupting network availability through computational exhaustion rather than direct exploitation of consensus logic or private key compromise. The attack leverages the inherent asymmetry between the low cost of generating invalid proof structures and the high cost of attempting their verification by honest nodes.
To mitigate this vulnerability, it is essential for developers to implement stricter pre-validation checks on incoming transactions before they are enqueued for Halo2 proof verification. This includes validating that cryptographic proofs contain non-zero data where required and rejecting malformed structures early in the processing pipeline to prevent them from consuming shared resources. Additionally, implementing rate limiting or priority queues for transaction verification can help ensure that legitimate traffic is not starved by malicious floods of invalid transactions. Upgrading to Zebra version 6.2.1 or later resolves this issue as it includes patches designed to handle these edge cases more efficiently and securely. Network operators should also consider monitoring node performance metrics related to proof verification latency to detect potential abuse patterns early, allowing for proactive mitigation strategies such as temporary peer blacklisting if anomalous traffic volumes are observed from specific sources.