Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🦀 crates.io
Not in CISA KEV

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

Published
May 7, 2026
Updated
May 21, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed
Exploitation data as of May 21, 2026 · OSV.dev, FIRST.org (EPSS)

Real-World Exposure

1 pkg affected
🦀zebrad

Real-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: 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:

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:

PoC

Validated commits:

  • zcashd: 2c63e9aa08cb170b0feb374161bea94720c3e1f5
  • Zebra: a905fa19e3a91c7b4ead331e2709e6dec5db12cb

Manual reproduction steps:

  1. Build an otherwise-valid V5 transaction with at least two transparent inputs and only one transparent output.
  2. Sign input 0 normally.
  3. Sign input 1 with canonical SIGHASH_SINGLE or SIGHASH_SINGLE|ANYONECANPAY.
  4. Use the digest returned by Zebra's ZIP-244 path, where the missing output contributes transparent_outputs_hash([]).
  5. Submit the transaction to Zebra and to zcashd.
  6. 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.

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.iozebradall versions4.4.0cargo update -p zebrad --precise 4.4.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    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.

  2. 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.

  3. 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.

  4. 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

# `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 `Zebr
O3 Security · Impact-Aware SCA

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.

GHSA-cwfq-rfcr-8hmp: zebrad | O3 Security