Zebra versions before 7.0.0 have a vulnerability where unauthenticated peers can stall the initial synchronization process by sending a forged checkpoint block body. This forged data causes the node to reject certain hashes and stop requesting further blocks until it is restarted. The issue is fixed in version 7.0.0.
Zebra versions before 7.0.0 have an inefficient algorithmic complexity vulnerability that allows unauthenticated peers to exhaust verification threads by submitting transactions with many transparent inputs. This causes quadratic digest recomputation under ZIP-244 or ZIP-243, stalling block verification for minutes. The issue is fixed in version 7.0.0.
Zebra zebrad versions prior to 7.0.0 contain a denial of service vulnerability where a malicious peer can stall checkpoint synchronization by cancelling the verifier rewind after a failed commit. This causes the verifier to reject honest blocks until the service is restarted. The issue is fixed in version 7.0.0.
ZcashFoundation Zebra versions before 7.0.0 contain a reachable assertion race condition that can be triggered by unauthenticated remote peers. This flaw allows malicious peers to abort the node by causing disconnection during a blocked outbound send. Attackers can exploit this by sending empty FindBlocks or FindHeaders replies and ceasing to read their socket, which leads to unresolved client response handling and termination of syncing nodes. The issue is fixed in version 7.0.0.
ZcashFoundation Zebra versions from 4.5.0 up to but not including 7.0.0 have a protection mechanism failure that causes honest peers to be banned incorrectly. This occurs because the software scores mempool lock-time rejections at the ban threshold, allowing attackers to trigger bans by broadcasting transactions locked until the current block height. Affected nodes may ban honest relaying peers for 24 hours or until they restart. The issue is fixed in version 7.0.0.
Zebra versions from 2.3.0 up to but not including 7.0.0 contain a denial of service vulnerability. This flaw allows unauthenticated peers to bypass misbehavior scoring by submitting transactions or blocks with invalid transparent scripts. Exploitation can lead to CPU exhaustion and repeated stalling of block synchronization.
Zebra zebrad versions 6.4.0 up to but not including 7.0.0 contain an inefficient algorithmic complexity issue in the mempool coinbase-maturity check. This inefficiency arises because the function Transaction::coinbase_spend_restriction() rebuilds the transaction's output list repeatedly for each spent outpoint, resulting in quadratic computational work. An attacker controlling a connected peer can exploit this by sending many unsigned transactions with numerous transparent inputs and outputs, which are rejected without penalty but cause verification threads to be pinned.
Zebra versions before 6.4.0 have an improper integrity validation vulnerability in the inbound gossip download path. This flaw allows unauthenticated peers to cause the dropping of new blocks without penalty by serving a block with a manipulated coinbase scriptSig. This manipulation triggers a behind-tip drop before consensus validation, delaying tip discovery for mining backends. The issue is fixed in version 6.4.0.
Zebra versions before 6.4.0 have a vulnerability where unauthenticated peers can cause excessive resource consumption by sending forged block bodies with valid header hashes. This forces the software to perform full proof verification unnecessarily, wasting computational resources and stalling synchronization for about 67 seconds. The issue affects proof verification for Sapling, Orchard, and Ironwood protocols.
ZcashFoundation Zebra versions 6.4.0 up to but not including 6.4.2 contain a vulnerability where parsing certain version 6 transactions causes an assertion failure that crashes the node. This occurs because the size computation during UnminedTx construction incorrectly assumes re-serialization of the Orchard bundle cannot fail, leading to an abort. Unauthenticated remote peers can exploit this by sending a single pre-handshake transaction message, causing a denial of service by crashing the node repeatedly.
Zebra versions prior to 4.5.0 contain a resource exhaustion vulnerability where remote peers can send oversized block locator vectors, causing excessive resource consumption. This leads to exhaustion of blocking-pool threads and degrades block validation, RPC, and mempool performance. The issue is fixed in versions 4.5.0 and 8.0.0.
Zebra before 6.0.0 contains a denial of service vulnerability that allows unauthenticated peers to stall Tokio workers by submitting mempool transactions requiring expensive synchronous script verification. Attackers can send non-standard high-sigop P2SH transactions that reach CachedFfiTransaction::is_valid() before standardness checks, saturating the verifier buffer and rendering the node unresponsive.
ZEBRA is a Zcash node written entirely in Rust. Prior to version 4.4.0, a composite denial-of-service vulnerability in Zebra's block discovery pipeline allows an unauthenticated remote attacker to permanently halt all new block discovery on a targeted node. The attack exploits three independent weaknesses in the gossip, syncer, and download subsystems — all exercisable from a single TCP connection — to create a monotonically growing block deficit that never self-heals. This issue has been patched in version 4.4.0.
ZEBRA is a Zcash node written entirely in Rust. Prior to version 4.4.0, Zebra's block validator undercounts transparent signature operations against the 20000-sigop block limit (MAX_BLOCK_SIGOPS), allowing it to accept blocks that zcashd rejects with bad-blk-sigops. A miner who produces such a block can split the network: Zebra nodes follow the offending chain while zcashd nodes do not. This issue has been patched in version 4.4.0.
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.
ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.0 and zebra-consensus version 5.0.1, a logic error in Zebra's transaction verification cache could allow a malicious miner to induce a consensus split. By matching a valid transaction's txid while providing invalid authorization data, a miner could cause vulnerable Zebra nodes to accept an invalid block, leading to a consensus split from the rest of the Zcash network. This would not allow invalid transactions to be accepted but could result in a consensus split between vulnerable Zebra nodes and invulnerable Zebra and Zcashd nodes. This issue has been patched in zebrad version 4.3.0 and zebra-consensus version 5.0.1.
ZEBRA is a Zcash node written entirely in Rust. Prior to zebrad version 4.3.0 and zebra-chain version 6.0.1, a vulnerability in Zebra's transaction processing logic allows a remote, unauthenticated attacker to cause a Zebra node to panic (crash). This is triggered by sending a specially crafted V5 transaction that passes initial deserialization but fails during transaction ID calculation. This issue has been patched in zebrad version 4.3.0 and zebra-chain version 6.0.1.