Skip to content

GHSA-pvmv-cwg8-v6c8 CVE-2026-104435

Zebra v4.4.0 still accepts V5 SIGHASH_SINGLE without a corresponding output

High crates.io
Severity
0.0 / 10
High · CVSS 4.0
Exploit chance (EPSS)
0.21%
Chance of exploitation in the next 30 days. Higher than 10.45% 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
Available
2 packages have a fixed version

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:

  1. The signed hash type is not one of the six canonical values; and
  2. The hash type is SIGHASH_SINGLE (alone or combined with ANYONECANPAY) 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 vout entry with SIGHASH_SINGLE (0x03) or SIGHASH_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 versions

crates.io

PackageVulnerableFixed in
zebra-script
< 6.0.1
6.0.1
zebrad
< 4.4.1
4.4.1

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.

zebra-script crates.io → 6.0.1

cargo
cargo update -p zebra-script --precise 6.0.1

zebrad crates.io → 4.4.1

cargo
cargo update -p zebrad --precise 4.4.1

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:H/SC:N/SI:H/SA:H

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)
High
Confidentiality (subsequent systems)
None
Integrity (subsequent systems)
High
Availability (subsequent systems)
High

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

Timeline

  1. Published
  2. Last updated by the source
  3. Latest EPSS score
AdvisorySeverityWhy 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
Is this in your code?

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