GHSA-cwfq-rfcr-8hmp CVE-2026-104437
Zebra's Transparent SIGHASH_SINGLE Handling Diverges from zcashd for Corresponding Outputs
- Severity
- 0.0 / 10
- High · CVSS 4.0
- Exploit chance (EPSS)
- 0.25%
- Chance of exploitation in the next 30 days. Higher than 16.07% of scored vulnerabilities.
- Known exploited
- No
- Not in CISA's catalog
- Weakness
- CWE-354 Improper Validation of Integrity Check Value
- CWE-573 Improper Following of Specification by Caller
- Fix
4.4.0- Upgrade zebrad to this version or later
Description
Zebra Transparent SIGHASH_SINGLE Corresponding-Output Handling Diverges From zcashd
Summary
For V5+ transparent spends, Zebra and zcashd disagree on the same consensus rule: SIGHASH_SINGLE must fail when the input index has no corresponding output. zcashd treats this as consensus-invalid under ZIP-244, while Zebra's transparent verification path computes a digest for the missing-output case instead of failing.
The result is a direct block-validity split. A malformed V5 transparent transaction can be accepted by Zebra, retained in Zebra's mempool, selected into Zebra getblocktemplate, mined into a block, and then rejected by zcashd.
Details
Validated code revisions used during analysis:
zcashd:2c63e9aa08cb170b0feb374161bea94720c3e1f5Zebra:a905fa19e3a91c7b4ead331e2709e6dec5db12cb
Scope note:
- earlier triage material grouped pre-V5 and V5 behavior together;
- re-execution on the pinned revisions did not reproduce the claimed pre-V5 / V4 reject-side behavior;
- this advisory therefore covers the V5+ / ZIP-244 variant only.
zcashd side:
- Transparent scripts in blocks are checked through
TransactionSignatureChecker::CheckSig()andSignatureHash():zcash/src/script/interpreter.cpp. - In the ZIP-244 branch,
SignatureHash()explicitly throws whenSIGHASH_SINGLEorSIGHASH_SINGLE|ANYONECANPAYis used withnIn >= txTo.vout.size():zcash/src/script/interpreter.cpp. CheckSig()catches that exception and returnsfalse, causing the transparent script to fail.
Zebra side:
- V5 transparent inputs route into the same FFI-based transparent script verifier used for block validation:
zebra/zebra-consensus/src/transaction.rs. Zebraconverts the decoded hash type and asks its Rust sighash engine for a digest without adding the corresponding-output pre-check thatzcashdenforces first:zebra/zebra-script/src/lib.rs,zebra/zebra-chain/src/primitives/zcash_primitives.rs.Zebraforwards canonicalSIGHASH_SINGLEinto the Rust ZIP-244 implementation.- In that implementation, when
input.index() >= bundle.vout.len(), the code usestransparent_outputs_hash::<TxOut>(&[])instead of erroring:zcash_primitives/src/transaction/sighash_v5.rs,zcash_primitives/src/transaction/sighash_v5.rs.
Why this is exploitable:
- the malformed transaction only needs fewer transparent outputs than inputs;
- the attacker signs the digest that
Zebracomputes for the missing-output case; Zebrathen sees a valid transparent signature, whilezcashdnever reaches the same digest because it fails first.
Ordinary path viability:
zcashdordinary mempool admission is not the practical trigger path, because the same ZIP-244SignatureHash()checks fail there first:zcash/src/main.cpp,zcash/src/script/interpreter.cpp.Zebraordinary mempool admission is viable becauseZebrauses the same transparent verifier for mempool and block validation and does not have a separate "one output per input" standardness rule here:zebra/zebra-consensus/src/transaction.rs,zebra/zebrad/src/components/mempool/storage.rs.Zebrais a block-template producer, so the realistic stock path isZebramempool ->Zebragetblocktemplate-> external miner:zebra/zebra-rpc/src/methods/types/get_block_template/zip317.rs.
PoC
Validated commits:
zcashd:2c63e9aa08cb170b0feb374161bea94720c3e1f5Zebra:a905fa19e3a91c7b4ead331e2709e6dec5db12cb
Manual reproduction steps:
- Build an otherwise-valid V5 transaction with at least two transparent inputs and only one transparent output.
- Sign input
0normally. - Sign input
1with canonicalSIGHASH_SINGLEorSIGHASH_SINGLE|ANYONECANPAY. - Use the digest returned by
Zebra's ZIP-244 path, where the missing output contributestransparent_outputs_hash([]). - Submit the transaction to
Zebraand tozcashd. - Observe:
Zebraaccepts it into the mempool;Zebraselects it intogetblocktemplate;Zebracan mine and accept a block containing it;zcashdrejects it in the ordinary mempool path.
Impact
This is a direct V5+ transparent consensus split.
Who can trigger it:
- an ordinary transaction author can craft the malformed V5 transparent transaction;
- the accept-side stock path is
Zebra's mempool and block-template path; - an external miner still has to include the transaction in a block for the split to materialize.
Who is impacted:
Zebracan accept and template a transaction / block thatzcashdrejects;- this makes the issue both a consensus-divergence problem and a practical
Zebrablock-template safety problem.
Affected versions
crates.io
| Package | Vulnerable | Fixed in |
|---|---|---|
| zebrad | < 4.4.0 |
4.4.0 |
How to fix
Move to the fixed version or later with your package manager, update the lockfile, and run your tests. If the package only arrives through another dependency, upgrade that dependency first. If none of its releases pulls a fixed version yet, force the version with your package manager's override.
zebrad crates.io → 4.4.0
- cargo
cargo update -p zebrad --precise 4.4.0
Severity breakdown
CVSS 4.0 0.0
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:H/SA:N
- Attack vector
- Network
- Attack complexity
- Low
- Attack requirements
- None
- Privileges required
- None
- User interaction
- None
- Confidentiality (vulnerable system)
- None
- Integrity (vulnerable system)
- High
- Availability (vulnerable system)
- None
- Confidentiality (subsequent systems)
- None
- Integrity (subsequent systems)
- High
- Availability (subsequent systems)
- None
CVSS 3.1 7.4
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H
- Attack vector
- Network
- Attack complexity
- High
- Privileges required
- None
- User interaction
- None
- Scope
- Unchanged
- Confidentiality
- None
- Integrity
- High
- Availability
- High
Weakness
CWE-354: Improper Validation of Integrity Check Value
The product does not validate or incorrectly validates the integrity check values or "checksums" of a message. This may prevent it from detecting if the data has been modified or corrupted in transmission.
How to prevent it
- Implementation: Ensure that the checksums present in messages are properly checked in accordance with the protocol specification before they are parsed and used.
CWE-573: Improper Following of Specification by Caller
The product does not follow or incorrectly follows the specifications as required by the implementation language, environment, framework, protocol, or platform.
References
Packages
Other links
Timeline
- Published
- Last updated by the source
- Latest EPSS score
Related advisories
| Advisory | Severity | Why it's related |
|---|---|---|
| GHSA-ww9q-8r59-xv46 Zebra: Missing copy constraint in halo2_gadgets variable-base scalar multiplication allows under-constrained base, breaking Orchard Action circuit soundness | Critical | Also affects zebrad |
| GHSA-63wg-wjjj-7cp8 Zebra Address Book Aborted by IPv4-Mapped Mempool Misbehavior Update | High | Also affects zebrad |
| GHSA-65jj-fmw8-468q zebrad has unbounded memory leak in mempool download pipeline via timeout path cancel_handles retention | Medium | Also affects zebrad |
| GHSA-2gf8-q9rr-jq3h zebrad has persistent on-disk corruption of Sapling/Orchard subtree roots after chain fork via pop_tip | Medium | Also affects zebrad |
| GHSA-hhm7-qrv5-h4r6 Zebra: Repeated Non-Finalized Shielded Transaction Aborts Zebra Before Duplicate-Nullifier Rejection | Medium | Also affects zebrad |
| GHSA-w834-cf6p-9m9w Zebra: Finalized address balance credit-first overflow on consensus-valid blocks | Medium | Also affects zebrad |
| GHSA-gvjc-3w7c-92jx Zebra has sync restart poisoning from single unauthenticated peer via above-lookahead block | Medium | Also affects zebrad |
| GHSA-gf9r-m956-97qx zebrad has consensus divergence via P2SH sigop undercount in pure-Rust disabled-opcode parser | Critical | Also affects zebrad |
MergeHarbor checks every repository's dependencies against this database, ranks what matters by exploitability and reachability, routes it to the owning team and opens the fix pull request.
Check your repos with MergeHarbor