CVE-2026-104435 in Zebra
Summary
by MITRE • 10/02/2026
Zebra zebrad 4.4.0 and zebra-script 6.0.0 fail to enforce a ZIP-244 consensus rule, accepting V5 transparent inputs signed with SIGHASH_SINGLE that lack a corresponding output. Attackers can broadcast crafted V5 transactions with more inputs than outputs that Zebra accepts but zcashd rejects, causing a network consensus split.
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 4.4.0 and zebra-script version 6.0.0 represents a critical deviation from the established consensus rules of the Zcash blockchain, specifically concerning ZIP-244. This protocol upgrade introduced significant changes to transaction validation logic, particularly regarding how transparent inputs are handled within V5 transactions. The core technical flaw lies in the failure of these specific software versions to properly enforce the requirement that every transparent input signed with SIGHASH_SINGLE must have a corresponding output. In standard cryptographic signing practices for this context, SIGHASH_SINGLE implies that the signature covers only one specific output index; however, under ZIP-244 rules, if no such output exists or is invalid, the transaction should be rejected outright to maintain network integrity. The affected implementations incorrectly accept these malformed transactions, thereby creating a divergence in validation logic between Zebra nodes and other major clients like zcashd.
This discrepancy leads directly to a severe operational impact characterized by a potential consensus split within the network. When an attacker broadcasts a crafted V5 transaction containing more inputs than outputs with SIGHASH_SINGLE signatures that lack corresponding outputs, compliant nodes running unaffected software will reject this transaction as invalid according to strict ZIP-244 enforcement. Conversely, vulnerable Zebra nodes accept and propagate these transactions. This creates a situation where different parts of the network operate on conflicting views of the valid state of the blockchain. Such divergence can lead to orphaned blocks, wasted computational resources for mining or staking, and potentially facilitate double-spending attacks if an attacker leverages this inconsistency to confuse validators about which chain is canonical. The integrity of the ledger relies on uniform validation rules across all participating nodes; any deviation undermines trust in the system's immutability and finality guarantees.
From a classification perspective, this vulnerability aligns with CWE-20 Improper Input Validation, as the software fails to adequately sanitize or verify incoming transaction data against expected structural constraints. Furthermore, it relates to CWE-841 Improvement of Encryption Algorithms, specifically in the context of signature verification logic failing to adhere to specified cryptographic protocols defined by the network standard. In terms of adversary tactics, this flaw could be exploited using techniques associated with MITRE ATT&CK T1567 Exploit Remote Services or potentially facilitating chain reorganization attacks if combined with other vulnerabilities, although primarily it serves as a vector for causing denial of service through consensus disruption rather than direct data theft. The exploitation requires the ability to broadcast transactions to vulnerable nodes, making network-level access or public mempool visibility sufficient for initial impact assessment.
Mitigation strategies must focus on immediate software updates and rigorous validation enhancements. Users running Zebra 4.4.0 or zebra-script 6.0.0 should upgrade to patched versions that correctly implement ZIP-244 consensus rules, ensuring that transparent inputs signed with SIGHASH_SINGLE are verified for the existence of corresponding outputs before acceptance into the mempool and subsequent block inclusion. Network operators should also consider implementing additional monitoring tools to detect anomalous transaction patterns indicative of this exploit attempt, such as transactions with mismatched input-output counts involving specific signature hash types. Regular security audits focusing on consensus rule implementation are essential to prevent similar discrepancies in future releases, ensuring that all nodes maintain a unified view of the blockchain state and preserving the overall stability and trustworthiness of the Zcash network infrastructure.