How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

352,427

Total vulnerabilities in the database

Zebra's Transparent SIGHASH_SINGLE Handling Diverges from zcashd for Corresponding Outputs — zebrad

Improper Validation of Integrity Check Value

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

Published: May 7, 2026
Updated: Jun 5, 2026
GHSA: GHSA-cwfq-rfcr-8hmp
Severity: Critical
Exploit:
CISA KEV:

No technical information available.

CWEs:

Affected Software
References

Software	From	Fixed in
zebrad	-	4.4.0

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.