EUVD-2026-61166
GHSA-gf9r-m956-97qx
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessFund and broadcast P2SH-spend tx with disabled-opcode redeem script
-
DeliveryZebra miner includes txs in a block
-
ExploitZebra undercounts sigops, accepts block
-
Executionzcashd counts true sigops, rejects with bad-blk-sigops
-
ImpactNetwork forks into Zebra and zcashd tips
Vulnerability Assessment
| Weakness |
CWE
ASVS 5.0
V15 - Secure Coding and Architecture Incorrect provision of specified functionality
|
| Exploitation Conditions | Exploitation requires the target network to have both Zebra and zcashd validators participating (true on Zcash mainnet and testnet by default), and requires an attacker to broadcast transactions that spend P2SH outputs whose redeem scripts contain one of the 16 disabled opcodes (0x7e-0xab, e.g., OP_CODESEPARATOR) followed by enough OP_CHECKSIG/OP_CHECKMULTISIG operations that the true block-wide sigop total crosses MAX_BLOCK_SIGOPS = 20,000 while Zebra's undercounted total does not. The attacker needs no mining capability, RPC access, authentication, or special privileges (CVSS PR:N) - only funds to pay transaction fees. The key limiting factor is that the attacker cannot mine the divergent block themselves: the poisoned transactions must be picked up and included by an independent Zebra miner (estimated ~30% of network hashrate), so the split is triggered indirectly rather than at the attacker's direct command; there is no non-default configuration or platform restriction reducing exposure. |
| Impact | This is a genuine network-integrity priority for the Zcash ecosystem rather than an inflated high-CVSS number, but its blast radius is confined to Zcash node operators. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) reflects a remote, low-complexity, unauthenticated trigger with high impact to both the vulnerable system integrity (VI:H) and subsequent systems (SI:H/SA:H) - appropriate because a chain split propagates to every downstream validator and every block extending the diverged tip. No EPSS score, KEV listing, or public exploit code was provided, so exploitation is inferred-feasible rather than observed; the advisory nonetheless supplies a fully worked example (a [0xab, OP_CHECKMULTISIG x50] redeem script yields Zebra=0 vs zcashd=1,000 sigops, and 21 such inputs cross the 20,000 threshold). One real limiting factor is not captured by the CVSS metrics: the attacker cannot directly mine the poisoned block and must rely on an independent Zebra miner including the broadcast transactions - feasible given Zebra's estimated ~30% hashrate but not fully under attacker control. Note the provided 'Authentication Bypass' tag is inaccurate; this is a consensus/validation divergence, not an authentication bypass, and should be disregarded. |
| Exploit ScenarioDerived | An attacker with no mining capability funds a P2SH output whose redeem script places a disabled opcode (e.g., OP_CODESEPARATOR, 0xab) ahead of many OP_CHECKMULTISIG operations, then broadcasts transactions spending those outputs across the network for the cost of ordinary transaction fees. When a Zebra miner includes these transactions in a block, Zebra undercounts the sigops and accepts the block while zcashd computes the true count, exceeds MAX_BLOCK_SIGOPS, and rejects it with bad-blk-sigops. No public exploit code is identified, but the advisory documents a concrete reproduction and the low CVSS complexity (AC:L) makes crafting the redeem script straightforward. |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv2 – Aug 18, 2026
Consensus divergence in the Zcash Foundation's Zebra node (zebrad up to and including v4.4.1) lets remote unauthenticated attackers force a chain split between Zebra and zcashd validators. Zebra's P2SH signature-operation counter short-circuits on disabled script opcodes and returns a partial count, so it can accept a block that zcashd rejects for exceeding MAX_BLOCK_SIGOPS (20,000); an attacker only needs to broadcast transactions spending P2SH outputs with crafted redeem scripts and wait for any Zebra miner (~30% of network hashrate) to mine them. There is no public exploit identified at time of analysis and it is not on CISA KEV, but the advisory includes a concrete, reproducible technique, and the CVSS 4.0 score is 9.3.
Earlier versions of this analysis (1)
Consensus divergence in the Zcash Foundation's Zebra node (zebrad up to and including v4.4.1) lets a remote, unauthenticated attacker force a chain split between Zebra and zcashd validators without any mining capability. Zebra's P2SH signature-operation counter runs a pure-Rust path that short-circuits on disabled opcodes and undercounts sigops, so Zebra accepts blocks that zcashd rejects once the 20,000 block-sigop limit is straddled. There is no public exploit identified at time of analysis, but the advisory includes a concrete crafted redeem script demonstrating the divergence, and all default configurations are affected.
RemediationAI
Upgrade zebrad to the fixed release: per the structured advisory data and the Zebra 4.5.0 CHANGELOG (released 2026-05-28), zebrad is fixed in 4.5.0 and the zebra-script crate is fixed in 7.0.0; the fix routes the P2SH sigop counter through the same legacy_sigop_count_script C++ FFI already used by the legacy path so it matches zcashd's CScript::GetSigOpCount(true) exactly (commit 1440b43ca7df59aca948090d45117557b217a6cd). Note a documentation discrepancy: the advisory prose states 'Patched in Zebra 4.4.2,' while the machine-readable patch metadata, release tag, and CHANGELOG all confirm 4.5.0 - treat 4.5.0 as the confirmed released fix and verify with the vendor if 4.4.2 is expected in your channel. There is no configuration-level workaround: the vulnerability is in default consensus validation, so no feature can be disabled to mitigate it, and any Zebra node validating on a network shared with zcashd remains exposed until upgraded. Advisory and release references: https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-gf9r-m956-97qx and https://github.com/ZcashFoundation/zebra/releases/tag/v4.5.0.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 3 packages in cargo, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Zebra is a Rust reimplementation of the Zcash consensus node, running alongside the reference C++ implementation zcashd on the same networks; both must agree bit-for-bit on block validity or the chain forks. The flaw (CWE-684, incorrect provision of specified functionality) lives in how sigops are statically counted for Pay-to-Script-Hash inputs. The legacy sigop path in zebra-script/src/lib.rs:282-289 correctly delegates to the C++ FFI via interpreter.legacy_sigop_count_script(), but the P2SH path at lib.rs:399 instead calls the pure-Rust script::Code(redeemed_bytes).sig_op_count(true) in zcash_script-0.4.4. That Rust parser (opcode/mod.rs:1247-1260) classifies 16 disabled opcodes in the 0x7e-0xab range (OP_CAT, OP_SUBSTR, OP_AND/OR/XOR, OP_2MUL/2DIV, OP_MUL/DIV/MOD, OP_LSHIFT/RSHIFT, OP_CODESEPARATOR, etc.) as Err(Error::Disabled), and sig_op_count uses try_fold (iter.rs:104-115), which stops at the first Err and returns only the sigops accumulated before it. zcashd's GetSigOpCount(true) (script.cpp:152-174, via GetOp2 in script.h:514-562) keeps counting past disabled opcodes and only rejects them at execution time, so the two implementations produce different counts for the same script.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:H
Remote, unauthenticated, low-complexity broadcast (AV:N/AC:L/PR:N/UI:N); scope-changed (S:C) because the split impacts the wider network beyond the node, with high integrity and no confidentiality/availability impact.
Primary rating from Vendor (https://github.com/ZcashFoundation/zebra).
CVSS VectorVendor: https://github.com/ZcashFoundation/zebra
Lifecycle Timeline
2DescriptionCVE.org
Am I affected
You are affected if:
- You run any version of
zebradup to and includingv4.4.1. - Your node validates blocks on mainnet, testnet, or any network where both Zebra and zcashd nodes participate.
All default configurations are affected. No feature flags, non-default settings, or special build options are required.
Summary
Zebra's P2SH sigop counter uses a pure-Rust code path that short-circuits on disabled opcodes (such as OP_CODESEPARATOR), returning a partial count of zero for any sigops following the disabled opcode. The reference implementation (zcashd) correctly counts through disabled opcodes in its static sigop analysis. This produces a consensus divergence: Zebra accepts blocks that zcashd rejects when the block-wide MAX_BLOCK_SIGOPS = 20,000 threshold is crossed on one side but not the other.
An attacker can exploit this without mining capability. Broadcasting transactions that spend P2SH outputs with malicious redeem scripts is sufficient; any Zebra miner who includes those transactions in a block triggers a chain split between Zebra and zcashd validators.
Details
The P2SH sigop counter at zebra-script/src/lib.rs:399 calls script::Code(redeemed_bytes).sig_op_count(true), which is a pure-Rust path through zcash_script-0.4.4. The legacy (non-P2SH) sigop counter at lib.rs:282-289 correctly uses the C++ FFI via interpreter.legacy_sigop_count_script(). Only the P2SH path bypasses the FFI.
The Rust parser in zcash_script-0.4.4/src/opcode/mod.rs:1247-1260 treats 16 disabled opcodes (0x7e through 0xab, including OP_CAT, OP_SUBSTR, OP_AND, OP_OR, OP_XOR, OP_2MUL, OP_2DIV, OP_MUL, OP_DIV, OP_MOD, OP_LSHIFT, OP_RSHIFT, and OP_CODESEPARATOR) as Err(Error::Disabled(...)). The sig_op_count function at iter.rs:104-115 uses try_fold, which terminates on the first Err and returns the partial sum accumulated so far.
zcashd's GetOp2 (script.h:514-562) returns true for all non-push opcodes including the disabled range. Its GetSigOpCount(true) (script.cpp:152-174) continues counting through disabled opcodes. zcashd rejects disabled opcodes at execution time in the interpreter, not during static sigop analysis.
A redeem script of [0xab, OP_CHECKMULTISIG x 50] produces: Zebra = 0 sigops, zcashd = 1,000 sigops. Across 21 inputs in a block, Zebra computes 0 while zcashd computes 21,000, crossing the MAX_BLOCK_SIGOPS = 20,000 threshold on one side only.
Patches
Patched in Zebra 4.4.2. The fix routes the P2SH sigop counter through the same C++ FFI already used by the legacy sigop counter.
Workarounds
There is no configuration-level workaround. All Zebra nodes validating blocks on a network shared with zcashd are affected. Upgrade as soon as the patched version is available.
Impact
A chain split between Zebra and zcashd validators. The attacker broadcasts spending transactions referencing P2SH outputs whose redeem scripts contain a disabled opcode followed by OP_CHECKSIG or OP_CHECKMULTISIG opcodes. When a Zebra miner (estimated ~30% of current network hashrate) includes these transactions in a block, Zebra validators accept the block while zcashd validators reject it with bad-blk-sigops. The two halves of the network diverge and every subsequent block extending the Zebra-side tip inherits the divergence.
The attacker does not need mining capability, RPC access, or any special privileges. The cost is the transaction fees for the funding and spending transactions.
Credit
Reported by @samsulselfut via a private GitHub Security Advisory submission.
Executive ViewAI
A critical consensus validation flaw in Zebra nodes (Zcash Foundation) allows remote unauthenticated attackers to force blockchain splits between incompatible validator implementations, affecting approximately 30% of the Zcash network's mining capacity. Organizations operating Zebra validators face immediate risk of transactional divergence and loss of network consensus integrity if unpatched.
Apply vendor patch.
Threat Intelligence Overview
NVD
CVE.org
EPSS
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Exploit-DB