Skip to main content

Zebra (Zcash node) EUVDEUVD-2026-28653

| CVE-2026-41583 CRITICAL
Improper Following of Specification by Caller (CWE-573)
2026-05-08 security-advisories@github.com GHSA-8m29-fpq5-89jj
9.3
CVSS 4.0 · GitHub Advisory
Share

Severity by source

GitHub Advisory PRIMARY
9.3 CRITICAL
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/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
X

Lifecycle Timeline

4
Patch available
May 08, 2026 - 16:18 EUVD
Source Code Evidence Fetched
May 08, 2026 - 16:16 vuln.today
Analysis Generated
May 08, 2026 - 16:16 vuln.today
CVE Published
May 08, 2026 - 15:16 nvd
CRITICAL 9.3

DescriptionGitHub Advisory

ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.1 and prior to zebra-script version 5.0.2, after a refactoring, Zebra failed to validate a consensus rule that restricted the possible values of sighash hash types for V5 transactions which were enabled in the NU5 network upgrade. Zebra nodes could thus accept and eventually mine a block that would be considered invalid by zcashd nodes, creating a consensus split between Zebra and zcashd nodes. In a similar vein, for V4 transactions, Zebra mistakenly used the "canonical" hash type when computing the sighash while zcashd (correctly per the spec) uses the raw value, which could also crate a consensus split. This issue has been patched in zebrad version 4.3.1 and zebra-script version 5.0.2.

AnalysisAI

Consensus failure in Zebra nodes before 4.3.1 allows remote attackers to trigger network partitioning by submitting V4 or V5 transactions with invalid sighash hash types. After a refactoring removed critical validation logic from C++ FFI code, Zebra failed to enforce consensus rules restricting hash type values in transparent transaction signatures, creating divergence from zcashd nodes. Attackers can exploit this remotely without authentication (CVSS:4.0 AV:N/AC:L/PR:N) to partition the Zcash network and enable potential double-spend attacks. No public exploit identified at time of analysis, but GitHub advisory (GHSA-8m29-fpq5-89jj) confirms the attack mechanism and vendor-released patches are available.

Technical ContextAI

Zebra is a Rust-based implementation of the Zcash protocol that interfaces with Bitcoin Script verification code written in C++ via FFI for consensus-critical transparent transaction validation. During a refactoring to simplify this FFI boundary, parsing logic was moved from C++ to Rust using callbacks, but consensus validation of sighash hash types was inadvertently omitted from the Rust caller. The Zcash protocol restricts valid hash type values in transaction signatures (particularly for V5 transactions introduced in the NU5 network upgrade), and these restrictions are part of consensus rules shared with the reference zcashd implementation. Additionally, V4 transaction sighash computation incorrectly used canonical hash types instead of raw values as specified. This represents CWE-573 (Improper Following of Specification by Caller), where the calling code failed to maintain invariants expected by the called function. The vulnerability affects transparent transactions specifically, which use Bitcoin-inherited ECDSA signatures rather than Zcash's shielded transaction mechanisms.

RemediationAI

Immediately upgrade to zebrad version 4.3.1 or later and zebra-script version 5.0.2 or later, available from the Rust package repository and GitHub releases at https://github.com/ZcashFoundation/zebra. The fix is implemented in commit 1f605eca5c55e3b65229fa01a97d9aa84fd37447, which adds consensus validation of sighash hash types in the Rust caller before invoking C++ verification code, and corrects V4 sighash computation to use raw hash type values per specification. Full technical details are available in the GitHub security advisory at https://github.com/ZcashFoundation/zebra/security/advisories/GHSA-8m29-fpq5-89jj. If immediate patching is not feasible, SPECIFIC compensating controls include: (1) Temporarily disable acceptance of V4 and V5 transparent transactions via transaction policy rules if Zebra configuration supports this - this prevents exploitation but significantly reduces node functionality; (2) Deploy network-level monitoring to detect consensus divergence by comparing block acceptance between Zebra and zcashd nodes, enabling rapid detection of exploitation attempts; (3) For mining operations, switch to zcashd reference implementation until patching is complete, as most miners already run zcashd, reducing chain-split risk. Note these workarounds have severe trade-offs: disabling transaction types breaks core functionality, monitoring only detects attacks without preventing them, and switching implementations requires operational overhead. No workaround provides equivalent security to patching.

Share

EUVD-2026-28653 vulnerability details – vuln.today

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy