CVE-2026-52735: ZEBRA: Consensus divergence via P2SH sigop undercount in pure-Rust disabled-opcode parser
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.
Security readout for executives and security teams
Plain-English summary
Zebra versions before 4.5.0 can disagree with the reference Zcash implementation about whether a block is valid. A crafted transaction could lead a Zebra miner to produce a block accepted by Zebra but rejected by zcashd, potentially splitting the chain and disrupting network integrity and availability.
Executive priority
Treat this as an urgent network-integrity update. Patch production Zebra miners and validators immediately, then confirm version coverage across backups, images, and automated deployments. A successful attack could split consensus and disrupt availability, although no active exploitation is established by the supplied sources.
Technical view
The pure-Rust P2SH signature-operation parser stops at disabled opcodes and returns its partial count. zcashd continues static counting, so signature operations after the disabled opcode are undercounted only by Zebra. Transactions may therefore appear below Zebra’s 20,000-operation block limit while exceeding zcashd’s limit. Version 4.5.0 corrects the discrepancy.
Likely exposure
Exposure is limited to Zcash Foundation Zebra nodes running versions earlier than 4.5.0. Zebra miners present the greatest immediate risk because including affected transactions can create a divergent block; outdated Zebra validators may then follow the incompatible chain. The bundle does not identify other affected products.
Exploitation context
The issue is remotely triggerable without privileges, user interaction, or attacker-controlled block production; an attacker could broadcast specially structured P2SH spends for a Zebra miner to include. The supplied record is not in KEV, and the cited bundle provides no evidence of active exploitation or observed chain splits.
Researcher notes
CWE-684 reflects incorrect behavior between implementations. The security boundary is consensus equivalence: Zebra’s error-short-circuiting parser returned a partial P2SH sigop count, unlike zcashd’s continued static counting. Assessment should focus on version provenance, miner participation, and evidence of cross-implementation validation disagreement. Do not interpret the critical score as evidence of exploitation.
Mitigation direction
Upgrade every Zebra node to version 4.5.0 or later.
Prioritize Zebra miners and validators participating in production consensus.
Confirm deployment procedures cannot retain or restore pre-4.5.0 binaries.
Review the vendor advisory and release notes for additional operational guidance.
Validation and detection
Inventory all Zebra instances and record their running versions.
Verify every production node reports version 4.5.0 or later.
Confirm deployed source or artifacts contain the vendor’s referenced correction.
Check monitoring for Zebra and zcashd validation disagreements or unexpected chain divergence.
Review historical alerts carefully; their absence does not prove the flaw was unexploited.
Generated from the cited source records. This long-tail analysis has not been individually reviewed by a named human.
Potential ATT&CK relevance
Conservative CVE-to-ATT&CK context
These mappings and lookup hints may be relevant to the vulnerability behavior, CWE, affected product, or exposure path. Glexia-inferred context is not an official MITRE, ATT&CK, CWE, or CVE Program mapping.
ATT&CK lookup starting points
Use these exact CWE pages and searches to review the Glexia ATT&CK library from this CVE's weakness and description context.
cwe · low confidence lookup
CWE-684: Exact CWE lookup
Use the exact CWE identifier as the starting point before reviewing related ATT&CK behavior. Open the exact CWE lookup page first, then review the ATT&CK searches from that MITRE weakness context. This is a Glexia lookup hint, not an official ATT&CK mapping.
These fields come from the CVE record and ADP containers, not from Glexia's Take. They preserve time-varying source decisions such as CISA SSVC, KEV status, CVSS metrics, and provider references.
We collect every scored CVSS vector available in the official CNA and ADP containers. When more than one version is present, the table keeps the source vectors side by side instead of collapsing them into the highest score.
CWE links open Glexia weakness intelligence pages with official CWE context, developer remediation guidance, and related CVE mappings.
CWE-684 · source CWE mapping
Incorrect Provision of Specified Functionality
Incorrect Provision of Specified Functionality represents a recurring weakness pattern that can create exploitable paths when design, validation, or implementation controls are missing.