CVE-2026-52735 in Zebra
Summary
by MITRE • 08/18/2026
ZEBRA is a Zcash node written entirely in Rust. Prior to 4.5.0, Zebra can accept a block that zcashd rejects because the P2SH signature-operation counter undercounts redeem scripts containing a disabled opcode followed by signature opcodes. In zebra-script/src/lib.rs, p2sh_input_sigop_count used the pure-Rust script::Code::sig_op_count path, whose try_fold parser stops at disabled opcodes such as OP_CODESEPARATOR and returns only the partial count accumulated before the error. The zcashd reference implementation continues static signature-operation counting through disabled opcodes, so an attacker can broadcast P2SH spends that Zebra counts below MAX_BLOCK_SIGOPS while zcashd counts above the 20,000-operation limit. If a Zebra miner includes those transactions, Zebra validators accept the block while zcashd validators reject it, creating a consensus chain split that affects network integrity and availability without requiring the attacker to produce a block. This issue is fixed in version 4.5.0.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/18/2026
The vulnerability identified in versions of Zebra prior to 4.5.0 represents a critical consensus divergence between the Rust-based Zebra node implementation and the reference C++ zcashd client, stemming from discrepancies in how signature operation counts are calculated for Pay-to-Script-Hash transactions. This flaw specifically affects the handling of redeem scripts that contain disabled opcodes followed by signature-related operations. In blockchain networks like Zcash, maintaining strict consensus on transaction validity is paramount to prevent chain splits and ensure network integrity. The core issue lies within the p2sh_input_sigop_count function located in the zebra-script/src/lib.rs module, which relies on a pure-Rust script parser path designated as Code::sig_op_count. This parser utilizes a try_fold mechanism that inherently stops processing upon encountering disabled opcodes such as OP_CODESEPARATOR and returns only the partial count accumulated up to that point rather than continuing the evaluation of subsequent instructions in the script.
In contrast, the zcashd reference implementation adheres strictly to protocol specifications by performing static signature-operation counting through all parts of a redeem script, including those following disabled opcodes. This fundamental difference in parsing logic allows an attacker to craft P2SH spends that exploit this discrepancy. By structuring transactions with specific sequences of disabled and signature opcodes, the attacker can cause Zebra nodes to significantly undercount the total number of signature operations required for validation. Consequently, these malformed transactions appear valid within the Zebra network because their calculated sigop count remains below the MAX_BLOCK_SIGOPS threshold, whereas zcashd validators correctly identify them as exceeding the 20,000-operation limit and reject them outright. This creates a scenario where transaction validity is not uniformly enforced across all nodes in the network.
The operational impact of this vulnerability extends beyond simple transaction rejection or acceptance; it poses a severe risk to consensus stability if exploited by miners. If an attacker broadcasts these specially crafted transactions, Zebra-based miners may include them in newly mined blocks since they pass local validation checks. However, when these blocks are propagated to zcashd nodes, the validators will reject the entire block due to the excessive signature operation count contained within it. This divergence leads to a consensus chain split where different parts of the network accept conflicting versions of the blockchain history. Such a split undermines the integrity and availability of the Zcash network, potentially leading to double-spending vulnerabilities or temporary forks that disrupt service for users relying on consistent ledger states. The attacker does not need to produce a block themselves but merely needs to broadcast transactions that trigger this validation mismatch in mining nodes running vulnerable versions of Zebra.
This vulnerability is classified under CWE-841, which pertains to Improper Enforcement of Behavioral Constraints, as the software fails to correctly enforce the rule regarding maximum signature operations per block due to flawed input parsing logic. From a threat modeling perspective aligned with MITRE ATT&CK techniques, this flaw facilitates Consensus Failure by allowing an adversary to cause nodes to diverge in their view of valid transactions, potentially leading to network instability or denial of service through chain splits. The issue highlights the critical importance of ensuring that alternative implementations maintain bit-level parity with reference clients regarding consensus-critical rules such as script execution and signature counting. To mitigate this risk, users must upgrade Zebra nodes to version 4.5.0 or later, where the parsing logic has been corrected to continue processing through disabled opcodes in accordance with the zcashd specification. Until all network participants have upgraded, there remains a theoretical possibility of consensus divergence if malicious transactions are mined into blocks by vulnerable miners.