Consensus Divergence in Zebra Zcash Implementation - Sighash Validation Bypass
Zebra failed to enforce consensus rules for V5 transaction sighash hash-type validation post-NU5 upgrade, and incorrectly processed V4 transaction hashes. This could allow malicious actors to create blocks accepted by Zebra but rejected by zcashd, causing network partition and double-spend risks.
CVE References
Affected
Vulnerability Analysis
Root Cause & Classification: This is a consensus validation failure stemming from post-refactoring code changes in Zebra's transparent transaction verification logic. The vulnerability exists in two distinct vectors: (1) missing validation of sighash hash-type constraints for V5 transactions introduced in the NU5 network upgrade, and (2) incorrect sighash computation for V4 transactions using canonicalized hash types instead of raw values per specification. The root cause traces to the FFI layer handling Bitcoin Script verification—during refactoring, critical consensus rules were inadvertently omitted.
Impact & Threat Model: This creates a consensus split vulnerability where Zebra nodes accept blocks that zcashd nodes reject. An attacker can craft transactions with invalid sighash hash-type values that bypass Zebra validation, potentially leading to: (a) network partitioning between Zebra and zcashd consensus, (b) double-spend attacks against liquidity providers relying on Zebra confirmation, (c) blockchain divergence requiring emergency coordination. Current risk is mitigated by zcashd network dominance among miners, but grows if Zebra adoption increases.
Detection Guidance: Monitor for: (1) Block validation inconsistencies between Zebra and zcashd nodes (fork detection systems should flag consensus divergence), (2) Transaction analysis: Flag V5 transactions with sighash values outside the permitted consensus set, (3) Log signatures: Search for validation failures in zcashd logs showing "bad-sighash" or "bad-txnversion" rejections not mirrored in Zebra logs, (4) Network behavior: Detect nodes remaining on divergent chain tips. Implement YARA-equivalent rules to inspect serialized transactions for out-of-spec hash-type bytes in V4/V5 witness data.
Mitigation Strategy: (1) Immediate: Upgrade all Zebra nodes to v4.3.1 or later where full sighash validation is restored, (2) Monitoring: Deploy consensus monitoring tools that cross-check block validity between implementation clients, (3) Policy: Operators should maintain mixed client diversity (Zebra + zcashd) during transition to catch divergence early, (4) Testing: Enhanced integration tests comparing sighash computation across implementations for V4/V5 transactions.
Risk Assessment: Exploitation likelihood is currently low due to zcashd dominance preventing obvious damage, but becomes high if: (a) Zebra market share grows significantly, (b) organized attack coordinating miners on Zebra nodes occurs, (c) V5 transaction adoption increases providing more attack surface. No public PoC exists; exploitation requires cryptographic sophistication and network coordination. Blockchain security researchers and sophisticated adversaries have clear motivation; the vulnerability is discoverable through protocol analysis.
Sources