CVE-2026-104430 in Zebra
Summary
by MITRE • 10/02/2026
Zebra zebrad 4.5.0 and zebra-script 7.0.0 count P2SH redeem script signature operations in legacy mode rather than zcashd's accurate P2SH mode, overcounting CHECKMULTISIG preceded by OP_1 through OP_16 as 20 sigops and causing a consensus divergence. Remote attackers can broadcast P2SH spends using low-threshold multisig redeem scripts so that a block zcashd accepts exceeds Zebra's inflated MAX_BLOCK_SIGOPS count, causing Zebra nodes to reject it and stall off the chain.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/02/2026
The vulnerability identified in Zebra versions 4.5.0 through related releases involves a critical consensus divergence between the Rust-based implementation of the Zcash protocol and the reference C++ implementation known as zcashd. This discrepancy arises from an incorrect calculation of signature operations, specifically within Pay-to-Script-Hash (P2SH) transactions. In blockchain protocols like Zcash, every transaction must include a precise count of cryptographic signature verification operations to ensure that blocks do not exceed network-defined limits designed to prevent denial-of-service attacks through computational exhaustion. The standard for counting these operations is defined by the Bitcoin script semantics adopted by Zcash, where specific opcodes trigger fixed costs regardless of whether they are executed or merely present in an unexecuted branch of a conditional script structure.
The core technical flaw lies in how Zebra handles legacy P2SH redeem scripts compared to zcashd. Specifically, when processing multisig operations preceded by the opcodes OP_1 through OP_16, which represent threshold values for CHECKMULTISIG instructions, Zebra incorrectly applies legacy counting rules rather than the accurate modern accounting method used by zcashd. Under the flawed logic in Zebra, these specific configurations are counted as twenty signature operations each. In contrast, zcashd correctly identifies that such structures should be counted differently under standard P2SH semantics, typically assigning a lower or distinct value depending on the exact script structure and versioning rules applied at the time of block validation. This misalignment means that Zebra systematically overestimates the computational cost associated with these specific multisig transactions during its consensus verification process.
The operational impact of this vulnerability is severe because it directly affects blockchain synchronization and network stability. An attacker can exploit this discrepancy by broadcasting a specially crafted P2SH spend transaction that utilizes low-threshold multisig redeem scripts structured to trigger the overcounting behavior in Zebra nodes. When such transactions are included in a block, the total signature operation count calculated by zcashd will be lower than what is calculated by vulnerable versions of Zebra. Consequently, while zcashd validates and accepts the block as legitimate because it falls within the MAX_BLOCK_SIGOPS limit, Zebra nodes reject the same block due to their inflated calculation exceeding this threshold. This results in a consensus split where different parts of the network disagree on the validity of recent blocks, causing vulnerable Zebra nodes to stall off the main chain or potentially fork into an invalid branch if not properly handled by higher-level synchronization logic.
This vulnerability aligns with CWE-841, which pertains to Improper Enforcement of Consensus Rules, as it involves a failure in correctly applying protocol-specific validation rules that are critical for maintaining network integrity. Furthermore, from the perspective of the MITRE ATT&CK framework, this scenario relates to techniques involving resource exhaustion and consensus manipulation, specifically how an adversary can leverage implementation differences to disrupt service availability or cause chain divergence. The attack vector is remote and does not require authentication, allowing any actor on the peer-to-peer network to broadcast the malicious block containing the problematic transactions.
Mitigation for this issue requires immediate software updates to ensure that all Zebra nodes are running a version where the P2SH signature operation counting logic has been corrected to match zcashd's implementation. Network administrators should monitor their node logs for rejection messages related to MAX_BLOCK_SIGOPS and verify that they are synchronized with peers running patched versions of the client. Until all nodes in the network upgrade, there remains a risk of temporary chain splits or delayed synchronization for vulnerable nodes when blocks containing these specific multisig structures are mined by zcashd miners. Long-term resilience against such consensus bugs relies on rigorous cross-implementation testing and fuzzing strategies that specifically target edge cases in script evaluation to ensure parity between independent implementations of the protocol specification.