Listen to this Post
How the CVE works (around 20 lines):
The vulnerability stems from a refactoring in Zebra (a Zcash node implementation) that altered how transparent transaction signatures are verified. Zebra previously used a foreign function interface (FFI) to call C++ Bitcoin Script verification code. After refactoring, only the verification logic remained in C++, with Rust code handling the rest via a callback. During this change, developers missed a critical consensus rule: only known sighash hash-type values are allowed in transparent transaction signatures. For V5 transactions (enabled by the NU5 upgrade), Zebra stopped enforcing this restriction, while zcashd (the reference Zcash node) still enforces it. An attacker can submit a V5 transaction with an invalid hash type; Zebra accepts it, zcashd rejects it. Similarly, for V4 transactions, Zebra mistakenly used the “canonical” hash type instead of the raw hash value when computing the sighash, diverging from zcashd. This creates a consensus split where Zebra nodes may mine or accept blocks that zcashd nodes consider invalid. The attack is network-based: the attacker broadcasts a specially crafted transaction. If a Zebra node mines a block containing such a transaction, the block will be rejected by zcashd nodes, causing a permanent fork. This can lead to double-spends, service disruption, and network partitioning. The severity is critical because it breaks consensus between two major node implementations. However, the impact is mitigated because most miners still run zcashd, limiting the attacker’s ability to cause a chain split. Affected versions are all Zebra prior to 4.3.1. The fix adds the missing consensus check in the Rust caller and corrects the V4 sighash computation to use the raw hash type.
dailycve form:
Platform: Zebra node
Version: < 4.3.1
Vulnerability: Consensus sighash split
Severity: Critical
date: 2023-07-19 (approx)
Prediction: Patch already released (2023-07-19)
What Undercode Say:
Check Zebra version zebrad --version | grep -E "zebrad [0-9]+.[0-9]+.[0-9]+" Simulate invalid sighash type (V5 tx) echo "0200000001..." | xxd -r -p | zebrad debug check-tx --sighash-type 0xFE Verify consensus rule in Rust caller (fixed in 4.3.1) grep -r "SIGHASH_TYPE" zebra-chain/src/transparent/sighash.rs Compare sighash computation between zebrad and zcashd diff <(zebrad compute-sighash tx.hex 4) <(zcash-cli computesighash tx.hex 4)
Exploit:
Attacker crafts a V4 or V5 transparent transaction with a non-standard sighash hash-type (e.g., 0xFE). Broadcasts it to a Zebra node <4.3.1. Zebra accepts and relays the transaction. If the attacker mines a block containing that transaction, Zebra nodes accept the block, but zcashd nodes reject it. The network splits; the attacker can spend the same UTXO on the zcashd chain (double-spend).
Protection from this CVE:
Upgrade to Zebra 4.3.1 immediately. No workarounds. After upgrade, the consensus check rejects any transaction with unknown sighash hash-type. For V4, the raw hash type is used, matching zcashd. Node operators should also monitor for unexpected chain forks and verify block headers against a trusted zcashd node.
Impact:
Consensus failure leading to network partition. Malicious actor can cause double-spend attacks and service disruption. Any affected Zebra node can be isolated from the main chain. If miners use Zebra, a permanent chain split could occur, damaging Zcash network integrity.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
