CVE-2026-41583 Overview
CVE-2026-41583 affects Zebra, a Zcash node implementation written entirely in Rust by the Zcash Foundation. The vulnerability stems from a refactoring regression that broke validation of a consensus rule restricting sighash hash type values for V5 transactions introduced in the NU5 network upgrade. Zebra nodes accept and may mine blocks that zcashd nodes reject, producing a consensus split between the two implementations. A parallel defect affects V4 transactions, where Zebra uses the canonical hash type when computing the sighash instead of the raw value used by zcashd. Maintainers patched the issue in zebrad 4.3.1 and zebra-script 5.0.2.
Critical Impact
A network-reachable attacker can craft transactions that cause a consensus split between Zebra and zcashd nodes, threatening chain integrity across the Zcash network.
Affected Products
- zfnd zebrad prior to version 4.3.1
- zfnd zebra-script prior to version 5.0.2
- Zcash network nodes running vulnerable Zebra builds
Discovery Timeline
- 2026-05-08 - CVE-2026-41583 published to NVD
- 2026-05-08 - Last updated in NVD database
Technical Details for CVE-2026-41583
Vulnerability Analysis
The vulnerability is a consensus rule validation failure classified under [CWE-573] (Improper Following of Specification by Caller). Zebra implements the Zcash protocol alongside the reference zcashd node, and both must agree on transaction and block validity. A refactor in Zebra removed enforcement of the constraint that V5 transactions, enabled in the NU5 network upgrade, must use specific allowed values for the sighash hash type. Zebra accepts transactions with hash type values that zcashd rejects as invalid. For V4 transactions, Zebra computes the sighash using the canonical hash type value, while zcashd uses the raw byte value as specified by the protocol. The mismatch lets an attacker engineer transactions valid on one implementation and invalid on the other.
Root Cause
The root cause is incomplete enforcement of the Zcash protocol specification following a code refactor in the Zebra script verification path. Validation logic that previously rejected non-canonical sighash hash types for V5 transactions was lost. The V4 sighash computation diverges from the specification by normalizing the hash type before hashing.
Attack Vector
An attacker submits a crafted transaction to the Zcash peer-to-peer network with a sighash hash type that Zebra accepts but zcashd rejects, or vice versa for V4 sighash computation. When a Zebra-operated miner includes the transaction in a block, zcashd nodes reject the block while Zebra nodes accept it. The result is a chain split where the two implementations track different best chains. Exploitation requires only network access and no authentication.
No public proof-of-concept exploit is available. See the Zcash Foundation security advisory GHSA-8m29-fpq5-89jj for protocol-level details.
Detection Methods for CVE-2026-41583
Indicators of Compromise
- Zebra nodes reporting a best chain tip that diverges from zcashd nodes at the same height
- Block acceptance log entries on Zebra for transactions containing non-standard sighash hash type bytes in V5 transactions
- Reorganization events on Zebra nodes after peers reject mined blocks
Detection Strategies
- Compare block hashes at recent heights between local Zebra nodes and reference zcashd nodes to identify forks
- Inspect mempool transactions for V5 transactions carrying sighash hash type values outside the protocol-allowed set
- Monitor zebrad version strings across the fleet to identify nodes running builds prior to 4.3.1
Monitoring Recommendations
- Alert on any divergence between Zebra and zcashd chain tips exceeding one block
- Track peer disconnection rates and invalid-block rejections logged by neighboring nodes
- Aggregate zebrad and zebra-script version telemetry to confirm patch coverage across mining and validating infrastructure
How to Mitigate CVE-2026-41583
Immediate Actions Required
- Upgrade all zebrad deployments to version 4.3.1 or later
- Upgrade zebra-script to version 5.0.2 or later in any downstream integration
- Halt mining on Zebra nodes until patched binaries are deployed and chain tip parity with zcashd is confirmed
Patch Information
The Zcash Foundation released fixes in zebrad 4.3.1 and zebra-script 5.0.2. The patches restore validation of allowed sighash hash type values for V5 transactions and align V4 sighash computation with the protocol specification used by zcashd. Reference the GitHub Security Advisory GHSA-8m29-fpq5-89jj for release notes and commit references.
Workarounds
- Run a zcashd node in parallel and cross-validate accepted blocks before relying on Zebra's chain state
- Restrict inbound peer connections to trusted nodes that operate patched software
- Pause block production on Zebra-based mining infrastructure until upgrades are complete
# Verify installed Zebra versions and upgrade
zebrad --version
cargo install --locked --version 4.3.1 zebrad
cargo update -p zebra-script --precise 5.0.2
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
