Sangsoo-Osec

**Name of the Vulnerable Software and Affected Versions** Zebra versions 4.3.1 through 4.3.1 **Description** Insufficient error handling during sighash computation can lead to consensus divergence. When an invalid sighash type is encountered, the system fails to return an error, leaving the input sighash buffer untouched. If a previous signature validation left a valid sighash in the buffer, an invalid hash-type may be incorrectly accepted. This occurs because the foreign function interface (FFI) bridge only writes to the C++ sighash buffer when the Rust callback returns `Some`, but the C++ checker reads the buffer unconditionally, causing the failure signal to be lost. An attacker can exploit this by constructing a transparent output that executes a valid `OP CHECKSIGVERIFY` followed by an `OP CHECKSIG` with an undefined hash type, potentially inducing network partitioning, service disruption, and double-spend attacks. **Recommendations** Update to version 4.4.0.

**Name of the Vulnerable Software and Affected Versions** ZEBRA versions prior to 4.4.0 **Description** The block validator undercounts transparent signature operations against the 20000-sigop block limit `MAX BLOCK SIGOPS`, which allows the software to accept blocks that zcashd rejects. This discrepancy can enable a miner to split the network, as Zebra nodes would follow a chain that zcashd nodes reject. The issue stems from two undercounting errors: first, the `Sigops` implementation skipped the coinbase input entirely, allowing up to approximately 98 sigops to be hidden in the coinbase `scriptSig`. Second, Zebra failed to accumulate P2SH sigops during block validation, only computing them during the mempool-acceptance path. Consequently, blocks where the aggregate redeem-script sigops exceed 20000 are incorrectly accepted. **Recommendations** Update to version 4.4.0.

**Name of the Vulnerable Software and Affected Versions** Zebra versions prior to 4.3.1 **Description** A logic error in the transaction verification cache allows a malicious miner to induce a consensus split. The issue stems from a performance optimization that skips transaction validation if the transaction was previously accepted into the mempool. This mechanism fails to account for height-dependent validity, such as expiry heights, lock times, or network upgrades. An attacker could submit a transaction valid for height `H+1` but invalid for `H+2`, then mine it into a block at height `H+2`. Vulnerable nodes may accept the invalid block, leading to a chain fork and network partitioning from the rest of the Zcash network. **Recommendations** Update to Zebra version 4.3.1.

**Name of the Vulnerable Software and Affected Versions** zebrad versions prior to 4.3.1 zebra-script versions prior to 5.0.2 **Description** Following a refactoring of the verification process for transparent transactions, Zebra failed to validate a consensus rule restricting the possible values of sighash hash types for V5 transactions enabled in the NU5 network upgrade. Additionally, for V4 transactions, Zebra incorrectly used the canonical hash type when computing the sighash instead of the raw value. These issues could allow an attacker to submit transactions with invalid hash types, leading Zebra nodes to accept and potentially mine blocks that zcashd nodes would consider invalid, resulting in a consensus split and network partitioning. **Recommendations** Update zebrad to version 4.3.1 or later. Update zebra-script to version 5.0.2 or later.