CVE-2026-104431 in Zebra
Summary
by MITRE • 10/02/2026
Zebra before 6.0.0 contains a denial of service vulnerability that allows unauthenticated peers to stall Tokio workers by submitting mempool transactions requiring expensive synchronous script verification. Attackers can send non-standard high-sigop P2SH transactions that reach CachedFfiTransaction::is_valid() before standardness checks, saturating the verifier buffer and rendering the node unresponsive.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in Zebra versions prior to 6.0.0 represents a critical denial of service flaw rooted in the ordering of transaction validation logic within the mempool processing pipeline. This issue specifically targets the interaction between incoming peer connections and the internal Tokio worker threads responsible for handling network requests and block verification tasks. The core technical deficiency lies in the sequence of operations performed when validating new transactions received from unauthenticated peers. Instead of performing lightweight standardness checks first, the system allows certain non-standard transaction types to proceed directly into expensive synchronous script verification routines before their compliance with consensus rules is fully established. This architectural oversight creates a window where malicious actors can exploit the computational intensity of cryptographic signature verification to disrupt service availability.
Attackers leverage this flaw by submitting Pay-to-Script-Hash transactions that contain high sigop counts, which require significant CPU resources for elliptic curve digital signature algorithm verifications. These transactions are crafted specifically to bypass initial filtering mechanisms and reach the CachedFfiTransaction::is_valid() function before standardness checks can reject them based on size or complexity limits. Because these verification processes run synchronously within the Tokio worker threads, they block other critical operations such as handling new peer connections, processing incoming blocks, or responding to RPC requests. The result is a saturation of the verifier buffer, effectively stalling all dependent tasks and rendering the node unresponsive to legitimate network traffic.
From an operational perspective, this vulnerability allows any unauthenticated peer on the public internet to degrade the performance of a Zebra node significantly. By continuously submitting these high-cost transactions, an attacker can cause sustained resource exhaustion that impacts not only the affected node but potentially the broader network if multiple nodes are targeted simultaneously. This type of attack undermines the reliability and availability guarantees expected from blockchain infrastructure components. It is particularly dangerous because it does not require authentication or prior relationship with the node operator, making it accessible to a wide range of malicious actors seeking to disrupt consensus participation or mining operations.
The technical classification of this flaw aligns closely with CWE-400, which describes uncontrolled resource consumption leading to denial of service conditions. Furthermore, in terms of adversarial tactics, this behavior corresponds to ATT&CK technique T1496, Resource Hijacking, where attackers use compromised or vulnerable systems for their own computational purposes, although here the intent is purely disruptive rather than cryptomining. The specific mechanism involves manipulating input validation order to trigger expensive cryptographic operations, which can also be viewed through the lens of CWE-20 Improper Input Validation, as the system fails to adequately restrict inputs based on expected resource costs before processing them deeply within the application logic.
Mitigation strategies must focus on enforcing strict ordering in transaction validation pipelines and implementing rate limiting or cost-based filtering at earlier stages of the mempool entry process. Developers should ensure that standardness checks, including sigop limits and script complexity assessments, are performed synchronously and immediately upon receipt from peers, prior to any invocation of heavy cryptographic verification functions like CachedFfiTransaction::is_valid(). Additionally, implementing asynchronous processing for expensive operations can prevent blocking of Tokio workers, allowing the node to continue handling other critical tasks even under load. Upgrading to Zebra version 6.0.0 or later resolves this issue by correcting the validation sequence and adding safeguards against resource exhaustion attacks. Network operators should also consider deploying firewall rules or peer filtering mechanisms that restrict connections from untrusted sources until such patches are applied, thereby reducing the attack surface available to potential adversaries exploiting this vulnerability.