GHSA-cwfq-rfcr-8hmp — zebrad
GHSA-cwfq-rfcr-8hmp is a security vulnerability in zebrad. A fix is available for zebrad — see the affected versions and patch details below.
Zebra's Transparent SIGHASH_SINGLE Handling Diverges from zcashd for Corresponding Outputs
Real-World Exposure
zebradReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
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 Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | zebrad | all versions | 4.4.0cargo update -p zebrad --precise 4.4.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for zebrad, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update zebrad to 4.4.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-cwfq-rfcr-8hmp is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like GHSA-cwfq-rfcr-8hmp can be triaged on real exposure rather than presence alone.
Tailored to GHSA-cwfq-rfcr-8hmp. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-cwfq-rfcr-8hmp in your dependencies?
O3 Security finds GHSA-cwfq-rfcr-8hmp across crates.io dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.