CVE-2026-52735

Executive Summary

CVE-2026-52735 is a consensus-critical vulnerability affecting Zcash nodes running Zebra versions prior to 4.5.0. The flaw stems from differential signature-operation (sigop) counting logic between Zebra's pure-Rust implementation and zcashd (the reference C++ implementation), specifically in the calculation of P2SH signature-operation counts. An attacker can craft P2SH transactions that Zebra counts as under the 20,000-operation block limit while zcashd counts exceeding that limit, enabling the inclusion of invalid blocks. This discrepancy results in a consensus chain split between Zebra and zcashd validators, impacting network integrity and availability. If a Zebra-operated miner includes such transactions, the network can diverge, leading to economic and security risks for all Zcash participants. The vulnerability is fixed in Zebra 4.5.0; all nodes running earlier versions are affected.

Technical Analysis

The vulnerability resides in the signature-operation counting mechanism used to enforce the Zcash block-level limit of 20,000 signature operations (MAX_BLOCK_SIGOPS). During block validation, each transaction's signature operations are tallied, and transactions whose cumulative count exceeds the limit are rejected.

The divergence arises in zebra-script/src/lib.rs, specifically in the p2sh_input_sigop_count function. This function relies on the pure-Rust script::Code::sig_op_count path, which employs a try_fold parser to iterate through redeem scripts. The parser halts when it encounters disabled opcodes — such as OP_CODESEPARATOR — and returns only the partial count accumulated up to the point of the error.

In contrast, the zcashd reference implementation (written in C++) continues static signature-operation counting through disabled opcodes. It does not stop at OP_CODESEPARATOR; instead, it processes the entire script and accounts for all signature operations, including those following disabled opcodes.

This behavioral difference is exploited as follows:

1. An attacker crafts a P2SH redeem script that contains a disabled opcode (e.g., OP_CODESEPARATOR) followed by signature opcodes.
2. When Zebra processes this script via p2sh_input_sigop_count, the try_fold parser stops at OP_CODESEPARATOR, returning a partial count that omits the trailing signature operations.
3. zcashd processes the same script and counts ALL signature operations, including those after the disabled opcode.
4. The attacker can thus create a transaction that Zebra counts as, say, 5,000 sigops (well under the 20,000 limit) whereas zcashd counts as 25,000 sigops (above the limit).

The attack surface is the P2SH transaction validation path within block validation. This is not a network-level remote code execution; it is a logic flaw in consensus rules that allows for block acceptance divergence. The attack does not require producing a block — the attacker simply broadcasts crafted transactions. If a Zebra-operated miner (e.g., via pool software or a solo miner) includes these transactions in a block, that block will be accepted by Zebra validators but rejected by zcashd validators, causing a permanent chain split.

No specific code path beyond p2sh_input_sigop_count in zebra-script/src/lib.rs is provided in the NVD description. The flaw class is a consensus logic discrepancy (CWE-684 — Incorrect Provision of Specified Functionality), where two implementations of the same protocol rule diverge in behavior.

Exploitation Scenarios

Precondition: The attacker does not need to control a miner. The attack is viable if at least one Zebra-based miner includes crafted transactions in a block.

Step 1 — Reconnaissance/Target Identification: The attacker must identify which Zcash nodes and miners are running Zebra versions < 4.5.0. This can be accomplished by:

• Scanning the network for nodes advertising the Zebra user agent (e.g., via Zcash peer-to-peer protocol handshake responses).
• Monitoring block propagation and observing which blocks get orphaned — indicating a minority chain running diverging validation logic.
• Checking public node lists and mining pool configuration disclosures.

Step 2 — Flaw Activation: The attacker crafts a P2SH transaction whose redeem script structure is: {@OP_CODESEPARATOR}{one or more signature-opcode sequences}. The exact opcode sequence must ensure that the total number of signature operations exceeds 20,000 are counted by zcashd while Zebra's parser stops prematurely at the disabled opcode. This requires precise calculation of opcode weights to exploit the counting differential.

Step 3 — Payload/Execution: The crafted transaction is broadcast to the Zcash network. If a Zebra-based miner picks it up, the miner (running vulnerable Zebra) will include it in a candidate block because it believes the transaction complies with the sigop limit. The mined block propagates to the network, where:

• Zebra validators accept the block (since their sigop count is low).
• zcashd validators reject the block (since their sigop count is high).

Step 4 — Post-Exploitation Impact: Once a block containing the crafted transaction is accepted by Zebra nodes but rejected by zcashd nodes, the consensus rules diverge. Two separate chains emerge: the Zebra chain and the zcashd chain. This results in:

• A network split where transactions valid on one chain are invalid on the other.
• Potential double-spending opportunities, as funds can be spent on both chains before the split is resolved.
• Loss of consensus guarantees, undermining the integrity of the Zcash blockchain.
• Confirmation delays and orphaned blocks, degrading network availability.

Note: No public PoC exists; the attack chain is inferred from the vulnerability class and NVD description. The exact opcode sequences that trigger the counting differential have not been disclosed publicly.

Impact Assessment

Business Impact: This vulnerability compromises the foundational security property of a blockchain: consensus. A chain split undermines:

• Financial Integrity: Transactions finalized on one chain may be reversed on the other, enabling double spending and causing financial loss to exchanges, merchants, and users.
• Network Availability: The split degrades transaction confirmation reliability, harming all applications built on Zcash (e.g., privacy wallets, payment processors).
• Trust Erosion: While only Zebra nodes are directly affected, the entire Zcash ecosystem faces reputational damage and user confidence loss.

Affected Systems: All Zcash nodes (full nodes, miners, validators, infrastructure providers such as RPC providers and indexers) running Zebra versions prior to 4.5.0. zcashd nodes are the "canary" that will reject the malicious blocks, but they are not vulnerable in the sense of being the first to accept malicious data — they are the reference implementation that exposes the flaw.

Blast Radius: The attack is protocol-level. Every Zebra node that participates in block validation is a potential victim. If even a single Zebra miner accepts the malicious transaction, the entire network faces a split. The economic impact could be severe, potentially requiring a coordinated community effort to reach reconsensus (e.g., checkpointing or chain rollback).

CVSS: Not scored (N/A). The lack of scoring reflects the complexity of quantifying consensus-level failures. However, given the availability and integrity impact, if scored under CVSS 3.1 it would likely fall in the High to Critical range (7.0–9.0), factoring in the network attack vector (AV:N), high attack complexity (AC:H due to script crafting), no required privileges (PR:N), and no user interaction (UI:N), with High confidentiality/integrity/availability impact (C:H/I:H/A:H) due to chain divergence.

Detection Guidance

Detection is challenging because the malicious transactions may appear benign to lightweight inspection — they are only distinguishable by the sigop-counting logic of each node implementation. The following rules focus on detecting anomalous script patterns, node version discrepancies, and validation mismatches.

Sigma Rule

title: Zcash Redeem Script Suspicious Opcode Sequence
id: 8f3b9d1e-7c2a-4e5f-9a3b-6c8d2e1f4a5b
status: experimental
description: Detects P2SH redeem scripts containing OP_CODESEPARATOR followed by a high density of signature opcodes, potentially indicating CVE-2026-52735 exploitation.
logsource:
    category: application
    product: zebra
detection:
    selection:
        event.action: "TX_P2SH_VALIDATION"
        redeem_script_contains: "OP_CODESEPARATOR"
        sigop_count:
            - ">= 10000"
            - ">= 20000"
    condition: selection
falsepositives:
    - Legitimate multi-signature scripts that use OP_CODESEPARATOR for security.
level: high
tags:
    - attack.t1190
    - cve.2026-52735

YARA Rule

rule CVE_2026_52735_Sigop_Counting_Bypass
{
    meta:
        author = "ValtersIT Threat Intel"
        description = "Detects P2SH redeem scripts with OP_CODESEPARATOR followed by excessive signature opcodes."
        cve = "CVE-2026-52735"
        date = "2026-05-15"
    strings:
        $op_codeseparator = { AB }          // OP_CODESEPARATOR
        $op_checksig = { AC }               // OP_CHECKSIG
        $op_checksigverify = { AD }         // OP_CHECKSIGVERIFY
        $op_checkmultisig = { AE }          // OP_CHECKMULTISIG
        $op_checkmultisigverify = { AF }    // OP_CHECKMULTISIGVERIFY
    condition:
        $op_codeseparator and
        (#op_checksig >= 10 or #op_checksigverify >= 10 or
         #op_checkmultisig >= 10 or #op_checkmultisigverify >= 10)
}

Suricata IDS Rule

alert tcp any any -> any 8233 (msg:"Zcash CVE-2026-52735 P2SH Sigop Bypass Attempt"; content:"|AB|"; offset:0; depth:1; content:"|AC|"; distance:0; within:200; byte_test:4,>,20000,0,string,dec; flow:established,to_server; sid:202652735; rev:1; metadata:cve CVE-2026-52735; classtype:attempted-admin;)

Note: The above rule is heuristic — Suricata cannot natively parse Zcash protocol messages. In practice, detection should occur at the application layer (node logs) rather than network layer.

Elastic Detection

sequence by transaction.hash
  [ transaction where transaction.type == "P2SH_INPUT" and
    transaction.redeem_script contains "OP_CODESEPARATOR" ]
  [ transaction where transaction.sigop_count_zebra >= 10000 and
    transaction.sigop_count_zcashd >= 20000 ]

Note: Requires the node to log both Zebra-calculated and zcashd-calculated sigop counts for comparison, which is not standard behavior. Fallback: monitor for blocks that are accepted by Zebra but orphaned by the network.

Splunk SPL Query

index=zcash_node source=zebrad
| where event_type="block_validated" OR event_type="tx_accepted"
| regex redeem_script="(?i)OP_CODESEPARATOR"
| eval sigop_alarm = if(sigop_count >= 10000, "suspicious", "normal")
| where sigop_alarm == "suspicious"
| stats count by peer_ip, block_hash, transaction_hash
| where count > 5
| table _time, peer_ip, block_hash, transaction_hash, sigop_count

Wazuh OSSEC Rule

<group name="zcash,">
  <rule id="527350" level="12">
    <decoded_as>json</decoded_as>
    <field name="event_type">^(-?tx_accepted|block_validated)$</field>
    <field name="redeem_script" type="pcre">OP_CODESEPARATOR</field>
    <field name="sigop_count" type="pcre">^(\d{5,})$</field>
    <description>Zcash node: high sigop count in P2SH redeem script containing OP_CODESEPARATOR — CVE-2026-52735 indicator.</description>
    <group>cve_2026_52735,</group>
  </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED (no patch evidence from tracked sources). Note: Despite the "UNPATCHED" status in the intelligence feed, the NVD description explicitly states the issue is "fixed in version 4.5.0." This discrepancy likely reflects a lag in patch-source tracking. Operators should treat the fix as real and prioritize upgrading.

Immediate Mitigations (do not wait for full patch):

1. Node Decommission: Immediately take Zebra nodes offline from active mining/validation until upgraded. Replace them with zcashd nodes to maintain network consistency.
2. Transaction Filtering: Deploy a transaction relay policy on edge routers or proxies that blocks P2SH transactions containing OP_CODESEPARATOR where the total script length or estimated sigop count exceeds 10,000 (buffer margin below the 20,000 limit). This is defense-in-depth, not a complete fix.
3. Block Acceptance Policy: Configure long-running Zebra nodes to cross-validate newly received blocks against an external zcashd node before accepting them. Reject any block where zcashd returns an invalid response.

Patch/Upgrade Steps:

1. Monitor official Zcash/Zebra releases (https://github.com/ZcashFoundation/zebra/releases) for version 4.5.0 or later.
2. Back up node configuration and wallet data.
3. Perform a rolling upgrade: upgrade one node at a time to 4.5.0, verify chain state consistency, then proceed.
4. After all nodes are upgraded, verify network hashrate and block heights are aligned with the global chain.

Long-Term Hardening:

1. Heterogeneous Node Deployment: Operate a mix of Zebra and zcashd nodes to ensure no single implementation's logic flaw can silently diverge the network.
2. Consensus Test Suite: Establish a CI pipeline that runs the same test vectors on both Zebra and zcashd for every release, specifically covering script validation edge cases.
3. Proactive Auditing: Conduct regular audits of script validation code, focusing on opcode handling and static analysis of try_fold/iterator patterns that may prematurely terminate.
4. Incident Response Plan: Define a clear chain-split response protocol, including how to identify the canonical chain, how to notify miners, and how to coordinate a rollback if necessary.

References

1. NVD Entry: CVE-2026-52735 — https://nvd.nist.gov/vuln/detail/CVE-2026-52735 (NVD Description referencing zebra-script/src/lib.rs and fix in 4.5.0).
2. Zebra GitHub Repository: https://github.com/ZcashFoundation/zebra (Source code, issue tracker, and release timeline; monitor for fixed version 4.5.0 and related PR).
3. Zcash Foundation Blog: https://zfnd.org/blog (Official announcements for security advisories; check for a dedicated advisory on this CVE).
4. CWE-684 Reference: https://cwe.mitre.org/data/definitions/684.html (Incorrect Provision of Specified Functionality — describes the class of consensus-logic divergence).
5. CISA KEV: Not listed — CVE-2026-52735 is NOT in the Known Exploited Vulnerabilities catalog as of this report's date.

Threat Actor Activity: No known threat actor campaigns or in-the-wild exploitation evidence has been reported for this CVE at the time of writing. The vulnerability is consensus-logic in nature and requires specific mining conditions to be exploited, making it likely to be reserved for nation-state actors or sophisticated financially motivated groups targeting the Zcash ecosystem.