N/A

CVSS Score

-

CVSS Score

Basic Information

Concerned about an active attack path?

Talk to our security experts and see Miggo in action.

Miggo Vulnerability Database

→

GHSA-cwfq-rfcr-8hmp

GHSA-cwfq-rfcr-8hmp: Zebra's Transparent SIGHASH_SINGLE Handling Diverges from zcashd for Corresponding Outputs

`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: 2c63e9aa08cb170b0feb374161bea94720c3e1f5
Zebra: 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() and SignatureHash(): zcash/src/script/interpreter.cpp.
In the ZIP-244 branch, SignatureHash() explicitly throws when SIGHASH_SINGLE or SIGHASH_SINGLE|ANYONECANPAY is used with nIn >= txTo.vout.size(): zcash/src/script/interpreter.cpp.
CheckSig() catches that exception and returns false, 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.
Zebra converts the decoded hash type and asks its Rust sighash engine for a digest without adding the corresponding-output pre-check that zcashd enforces first: zebra/zebra-script/src/lib.rs, zebra/zebra-chain/src/primitives/zcash_primitives.rs.
Zebra forwards canonical SIGHASH_SINGLE into the Rust ZIP-244 implementation.
In that implementation, when input.index() >= bundle.vout.len(), the code uses transparent_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 Zebra computes for the missing-output case;
Zebra then sees a valid transparent signature, while zcashd never reaches the same digest because it fails first.

Ordinary path viability:

zcashd ordinary mempool admission is not the practical trigger path, because the same ZIP-244 SignatureHash() checks fail there first: zcash/src/main.cpp, zcash/src/script/interpreter.cpp.
Zebra ordinary mempool admission is viable because Zebra uses 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.
Zebra is a block-template producer, so the realistic stock path is Zebra mempool -> Zebra getblocktemplate -> external miner: zebra/zebra-rpc/src/methods/types/get_block_template/zip317.rs.

PoC

Validated commits:

zcashd: 2c63e9aa08cb170b0feb374161bea94720c3e1f5
Zebra: a905fa19e3a91c7b4ead331e2709e6dec5db12cb

Manual reproduction steps:

Build an otherwise-valid V5 transaction with at least two transparent inputs and only one transparent output.
Sign input 0 normally.
Sign input 1 with canonical SIGHASH_SINGLE or SIGHASH_SINGLE|ANYONECANPAY.
Use the digest returned by Zebra's ZIP-244 path, where the missing output contributes transparent_outputs_hash([]).
Submit the transaction to Zebra and to zcashd.
Observe:
- Zebra accepts it into the mempool;
- Zebra selects it into getblocktemplate;
- Zebra can mine and accept a block containing it;
- zcashd rejects 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:

Zebra can accept and template a transaction / block that zcashd rejects;
this makes the issue both a consensus-divergence problem and a practical Zebra block-template safety problem.

(GitHub Advisory)

Miggo Vulnerability Database

→

GHSA-cwfq-rfcr-8hmp

GHSA-cwfq-rfcr-8hmp:

N/A

CVSS Score

-

CVSS Score

Basic Information

Is this CVE running in your environment?

Easily map the attack path and prioritize which CVEs are a threat to your organization

Validate Exposure

Technical Details

Package Name	Ecosystem	Vulnerable Versions	First Patched Version
zebrad	rust	< 4.4.0	4.4.0

Technical Details

Vulnerability Intelligence
Miggo AI

Root Cause Analysis

The vulnerability lies in how Zebra, a Zcash implementation, handles SIGHASH_SINGLE for V5 transparent transactions. The Zcash consensus rules, as implemented in the reference client zcashd, require that a transaction input using SIGHASH_SINGLE must have a corresponding output at the same index. If not, the transaction is invalid. Zebra's implementation failed to enforce this rule.

Specifically, the function zebra_script::CachedFfiTransaction::is_valid would proceed to calculate a signature hash even when there were fewer outputs than inputs. An attacker could craft a transaction with, for example, two inputs and one output, and sign the second input with SIGHASH_SINGLE. Zebra would calculate a digest for this invalid scenario and, if the attacker provided a matching signature, would accept the transaction as valid. This transaction would be accepted into Zebra's mempool and could be included in a block template.

If a miner were to mine a block containing such a transaction, it would be accepted by Zebra nodes but rejected by zcashd nodes, leading to a consensus split or a fork in the Zcash network. This poses a significant risk to the integrity of the blockchain.

The patch addresses this by adding a crucial validation step in zebra_script::CachedFfiTransaction::is_valid. It now checks that the number of transaction inputs equals the number of previous outputs before attempting script verification. If the counts do not match, the function immediately returns an error, aligning Zebra's behavior with the zcashd reference implementation and closing the consensus vulnerability.

Vulnerable functions

zebra_script::CachedFfiTransaction::is_valid

zebra-script/src/lib.rs

This function was missing a check to ensure that the number of provided previous outputs matches the number of transaction inputs before proceeding with script verification. This allowed a SIGHASH_SINGLE transaction with fewer outputs than inputs to be considered valid by Zebra, contrary to the Zcash consensus rules. The patch adds a `.filter()` to enforce this check.

zebra_consensus::script::Verifier::call

zebra-consensus/src/script.rs

This service function orchestrates the script verification and calls the vulnerable `is_valid` function. The original code was susceptible to a panic on an out-of-bounds `input_index`. The patch hardens this by replacing direct array indexing with a `.get()` and proper error handling, which is a defense-in-depth measure related to the main vulnerability.

Vulnerability Intelligence
Miggo AI

Unlock WAF rules for this CVE

Generate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance

Get WAF rules

WAF Protection Rules

WAF Rule

W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.W** rul*s *v*il**l* *or Mi**o *ustom*rs only.

Reasoning

*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.*v*il**l* *or Mi**o *ustom*rs only.

N/A

-

Basic Information

Basic Information

Concerned about an active attack path?

GHSA-cwfq-rfcr-8hmp: Zebra's Transparent SIGHASH_SINGLE Handling Diverges from zcashd for Corresponding Outputs

Zebra Transparent SIGHASH_SINGLE Corresponding-Output Handling Diverges From zcashd

Summary

Details

PoC

Impact

GHSA-cwfq-rfcr-8hmp:

N/A

-

Basic Information

Basic Information

Is this CVE running in your environment?

Technical Details

Technical Details

Vulnerability IntelligenceMiggo AI

Root Cause Analysis

Vulnerable functions

Vulnerability IntelligenceMiggo AI

Unlock WAF rules for this CVE

WAF Protection Rules

WAF Rule

Reasoning

Technical Details

Basic Information

Basic Information

Vulnerability IntelligenceMiggo AI

Root Cause Analysis

Vulnerable functions

GHSA-cwfq-rfcr-8hmp: Zebra's Transparent SIGHASH_SINGLE Handling Diverges from zcashd for Corresponding Outputs

Zebra Transparent SIGHASH_SINGLE Corresponding-Output Handling Diverges From zcashd

Summary

Details

PoC

Impact

N/A

N/A

`Zebra` Transparent `SIGHASH_SINGLE` Corresponding-Output Handling Diverges From `zcashd`

Vulnerability Intelligence
Miggo AI

Vulnerability Intelligence
Miggo AI

Vulnerability Intelligence
Miggo AI

`Zebra` Transparent `SIGHASH_SINGLE` Corresponding-Output Handling Diverges From `zcashd`