Severity by source
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
Lifecycle Timeline
4DescriptionGitHub 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.
Remote attackers can crash ZEBRA Zcash nodes by submitting a crafted Orchard transaction containing an identity value in
Denial of service in Zebra's JSON-RPC HTTP middleware allows authenticated RPC clients to crash a Zebra node by disconne
Same technique Information Disclosure
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-28653
GHSA-8m29-fpq5-89jj