CVE-2026-104437 in Zebra
Summary
by MITRE • 10/02/2026
Zebra before 4.4.0 contains a consensus divergence vulnerability in V5 transparent signature verification, computing a ZIP-244 digest for SIGHASH_SINGLE inputs lacking corresponding outputs instead of failing. Attackers can craft V5 transactions with fewer outputs than inputs that Zebra accepts and templates via getblocktemplate, producing blocks zcashd rejects.
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in Zebra prior to version 4.4.0 represents a critical consensus divergence within the transparent signature verification logic of the Zcash blockchain protocol. This flaw specifically affects V5 transactions that utilize SIGHASH_SINGLE input types, which are designed to allow inputs to sign against their corresponding outputs while ignoring other inputs and outputs in the transaction structure. The core technical failure lies in how the software computes the ZIP-244 digest for these specific signature hashes. Instead of enforcing strict validation rules that require a one-to-one correspondence between inputs and outputs when SIGHASH_SINGLE is used, Zebra incorrectly calculates the cryptographic hash by treating missing corresponding outputs as valid or non-existent rather than triggering an immediate rejection. This deviation from the expected consensus behavior creates a scenario where the node accepts transactions that are technically invalid according to the broader network rules defined in ZIP-244 and the underlying Bitcoin-derived transaction format specifications.
The operational impact of this vulnerability is severe due to its potential to cause blockchain forks or chain splits within the Zcash network. Attackers can exploit this flaw by crafting V5 transactions that contain more inputs than outputs, a configuration that should be rejected during signature verification because SIGHASH_SINGLE requires each input to have at least one corresponding output to sign against. By submitting these malformed transactions through standard APIs such as getblocktemplate, an attacker could induce Zebra nodes to accept and propagate blocks containing invalid state transitions. Since the reference implementation zcashd correctly rejects these same transactions based on proper consensus rules, a divergence occurs where some validators consider the block valid while others deem it invalid. This inconsistency undermines the immutability of the ledger and can lead to temporary or permanent chain splits depending on which version dominates network hash power during the exploitation window.
From a security taxonomy perspective, this vulnerability aligns with CWE-841 Improper Enforcement of Behavioral Constraints, as the software fails to enforce the required structural constraints between transaction inputs and outputs for specific signature types. It also relates to CWE-20 Improper Input Validation because the node does not adequately verify that all necessary components exist before proceeding with cryptographic operations. In terms of adversarial tactics, this flaw facilitates actions consistent with ATT&CK technique T1615 Indirect Command Execution if leveraged in a broader attack chain involving block production manipulation, although its primary classification remains within consensus logic errors rather than direct command execution. The failure to reject invalid transaction structures allows for potential denial-of-service conditions through resource exhaustion or more sophisticated attacks targeting network stability and trust assumptions among participants.
Mitigation strategies require an immediate upgrade of all Zebra nodes to version 4.4.0 or later, where the consensus logic has been corrected to properly enforce ZIP-244 requirements during transparent signature verification. Network operators should monitor for blocks containing V5 transactions with SIGHASH_SINGLE inputs that lack corresponding outputs and report such anomalies to maintain network integrity until all peers are updated. Developers implementing custom Zebra integrations must ensure their transaction construction tools strictly adhere to the rule that every input in a SIGHASH_SINGLE signed transaction must have at least one output, preventing the generation of malformed transactions before they enter the mempool. Continuous monitoring and adherence to official security advisories from the Electric Coin Company are essential to prevent exploitation during any window where mixed versions exist within the network topology.