CVE-2026-104425 in Zebra
Summary
by MITRE • 10/02/2026
ZcashFoundation Zebra before 6.1.0 contains a resource exhaustion vulnerability that allows unauthenticated peers to degrade block processing by pushing transactions with invalid Orchard proofs without being misbehavior-scored. Attackers can repeatedly push invalid proofs into the shared halo2 batch verifier, forcing honest block proofs onto the slow individual-verification path and slowing block processing roughly sevenfold.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in Zebra versions prior to 6.1.0 represents a significant resource exhaustion flaw within the Zcash node implementation, specifically targeting the transaction validation pipeline for Orchard shielded transactions. This issue stems from an asymmetry in how invalid proofs are handled during peer-to-peer network interactions. When unauthenticated peers submit blocks or transactions containing malformed cryptographic data, the system fails to apply appropriate misbehavior scoring mechanisms that would typically penalize such malicious actors. Consequently, these nodes can repeatedly inject transactions with invalid Orchard zero-knowledge proofs into the shared halo2 batch verifier without facing immediate disconnection or reputation penalties. This lack of accountability allows attackers to sustain a high volume of fraudulent validation requests against honest node operators.
From a technical perspective, the core of this vulnerability lies in the behavior of the halo2 proof verification system used by Zcash for Orchard transactions. The implementation utilizes two distinct paths for verifying proofs: a fast batch verification path and a slower individual verification path. Under normal circumstances, valid proofs are processed efficiently through the batch verifier. However, when an invalid proof is detected during the initial stages of processing, rather than being rejected immediately with a penalty to the sender, the system falls back to the more computationally expensive individual-verification path for subsequent honest block proofs. This fallback mechanism was intended as a safety measure but has been exploited to create a denial-of-service condition. By forcing the node to process legitimate blocks through this slower pathway, attackers can artificially inflate computational overhead and memory usage associated with proof verification.
The operational impact of this vulnerability is severe, particularly for network participants who rely on timely block synchronization. The forced degradation of block processing results in an approximate sevenfold slowdown in how quickly a node can validate and propagate new blocks to the rest of the network. This latency disrupts the consensus mechanism by delaying the propagation of valid state changes across peers. For miners or validators, this increased lag reduces their competitiveness in producing new blocks, as they spend excessive time verifying incoming transactions rather than solving cryptographic puzzles. Furthermore, for full nodes acting as data sources for light clients, the slowed processing leads to outdated information being served, degrading the overall user experience and reliability of the network infrastructure.
This flaw aligns with CWE-400, which describes uncontrolled resource consumption, specifically manifesting here through excessive CPU utilization due to inefficient cryptographic verification loops. In terms of offensive security frameworks, this attack vector corresponds to MITRE ATT&CK technique T1496, Resource Hijacking, where an adversary uses computing resources for their own benefit or causes denial-of-service by exhausting system capacity. The specific method leverages the network layer (T1078) and exploits a logic flaw in input validation rather than a traditional buffer overflow or injection attack.
Mitigation strategies primarily involve upgrading to Zebra version 6.1.0 or later, where this resource exhaustion vector has been addressed by tightening the misbehavior scoring algorithms for invalid proofs. Node operators should ensure their software is updated promptly to prevent degradation of service during periods of high network activity. Additionally, implementing rate limiting at the peer connection level can provide an additional layer of defense against unauthenticated peers attempting to flood the node with malformed data. Monitoring CPU usage spikes correlated with block verification times may also serve as an early warning indicator for such attacks in older, unsupported versions until patches are applied.