CVE-2026-104435 — zebrad
CVE-2026-104435 is a CWE-347 vulnerability in zebrad. A fix is available for zebrad — see the affected versions and patch details below.
Zebra 4.4.0 Consensus Divergence via V5 SIGHASH_SINGLE Without Output
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-104435.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
zebrad🦀zebra-scriptReal-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
Consensus Divergence in V5 Transparent SIGHASH_SINGLE With No Corresponding Output
Summary
Zebra failed to enforce a ZIP-244 consensus rule for V5 transparent transactions: when an input is signed with SIGHASH_SINGLE and there is no transparent output at the same index as that input, validation must fail. Zebra instead asked the underlying sighash library to compute a digest, and that library produced a digest over an empty output set rather than failing. An attacker could craft a V5 transaction with more transparent inputs than outputs that Zebra accepts but zcashd rejects, creating a consensus split between Zebra and zcashd nodes.
A previous fix (GHSA-cwfq-rfcr-8hmp) addressed a closely related case in the same area of the code, but did not cover this specific one.
Severity
Critical - This is a Consensus Vulnerability that could allow a malicious party to induce network partitioning, service disruption, and potential double-spend attacks against affected nodes.
Note that the impact is currently alleviated by the fact that currently most miners run zcashd.
Affected Versions
Zebra 4.4.0.
Description
Verification of transparent transactions inherits the Bitcoin Script verification code in C++. Since it is consensus-critical, this code is called from Zebra through a foreign function interface (FFI), with a Rust callback that computes the sighash for each input being verified.
ZIP-244 §S.2a marks two situations as consensus failure for V5 transparent signatures:
- The signed hash type is not one of the six canonical values; and
- The hash type is
SIGHASH_SINGLE(alone or combined withANYONECANPAY) and the input has no transparent output at the same index.
zcashd enforces both rules: its SignatureHash raises an exception, and CheckSig catches it and fails the script. A previous fix (GHSA-cwfq-rfcr-8hmp) added the first rule to Zebra's V5 sighash callback. The second rule, however, was not added — Zebra's callback forwarded the request to librustzcash's ZIP-244 implementation, which handles an out-of-range SIGHASH_SINGLE output index by hashing an empty output set rather than refusing to produce a digest. As a result, Zebra would compute a well-defined sighash for the missing-output case and accept any signature that verified against it.
An attacker could exploit this by:
- Constructing a V5 transaction with two or more transparent inputs and fewer transparent outputs;
- Signing an input whose index has no matching
voutentry withSIGHASH_SINGLE(0x03) orSIGHASH_SINGLE|ANYONECANPAY(0x83), using the digest Zebra computes; - Broadcasting the transaction, or a block containing it, to the network.
Zebra would verify the transaction's transparent script and accept the transaction (and any block containing it), while zcashd would reject both, splitting Zebra nodes from the rest of the network.
Impact
Consensus Failure
- Attack Vector: Network.
- Effect: Network partition/consensus split.
- Scope: Any affected Zebra node.
Fixed Versions
This issue is fixed in Zebra 4.4.1.
Mitigation
Users should upgrade to Zebra 4.4.1 or later immediately.
There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains on the correct consensus path and is protected against malicious chain forks.
Credits
Zebra thanks @sangsoo-osec, @zmanian, and @fivelittleducks for finding and reporting the issue.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | zebrad | all versions | 4.4.1cargo update -p zebrad --precise 4.4.1 |
| 🦀crates.io | zebra-script | all versions | 6.0.1cargo update -p zebra-script --precise 6.0.1 |
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.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-104435 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.
Frequently Asked Questions
Is CVE-2026-104435 in your dependencies?
Find it across crates.io, including transitive dependencies.