Zebra vulnerabilities

Zebra before 6.4.0 contains an improper integrity validation vulnerability in the inbound gossip download path that allows unauthenticated peers to force dropping of new blocks without penalty. Attackers can serve a real block with a coinbase scriptSig rewritten to height 1, which keeps the ZIP-244 block hash, triggering a behind-tip drop before consensus validation and delaying tip discovery for mining backends.

Zebra before 4.5.0 contains an uncontrolled resource consumption vulnerability that allows remote P2P peers to exhaust blocking-pool threads by sending oversized block locator vectors. Attackers can send getblocks or getheaders messages with up to 65,535 locator hashes, triggering per-hash chain lookups that degrade block validation, RPC, and mempool performance.

Zebra zebrad 4.4.0 and zebra-script 6.0.0 fail to enforce a ZIP-244 consensus rule, accepting V5 transparent inputs signed with SIGHASH_SINGLE that lack a corresponding output. Attackers can broadcast crafted V5 transactions with more inputs than outputs that Zebra accepts but zcashd rejects, causing a network consensus split.

ZcashFoundation Zebra zebra-rpc before 8.0.0 and zebrad before 4.5.0 contain a reachable assertion in the z_listunifiedreceivers RPC handler, which calls expect() on Sapling receiver parsing that fails for Unified Addresses carrying invalid Jubjub points. Authenticated RPC clients can submit such an address to abort the zebrad process, repeatably keeping the node offline.

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 zebrad 4.5.0 and zebra-script 7.0.0 count P2SH redeem script signature operations in legacy mode rather than zcashd's accurate P2SH mode, overcounting CHECKMULTISIG preceded by OP_1 through OP_16 as 20 sigops and causing a consensus divergence. Remote attackers can broadcast P2SH spends using low-threshold multisig redeem scripts so that a block zcashd accepts exceeds Zebra's inflated MAX_BLOCK_SIGOPS count, causing Zebra nodes to reject it and stall off the chain.

Zebra (zebrad) 5.0.0 before 6.0.0-rc.0 does not apply its per-peer mempool admission cap to transactions received as direct P2P tx messages, because these are queued without the sending peer recorded as their source. A remote inbound peer can push many unique transactions to occupy a disproportionate share of mempool admission slots, crowding out honest peers' transaction relay.

Zebra before 6.1.0 contains an inefficient algorithmic complexity vulnerability in remaining_transaction_value that clones the entire block-level spent-UTXO map per transaction during contextual verification. Attackers can mine or seed the mempool with roughly 26,000 minimal single-input transactions in one block, stalling every validating node for over 52 seconds.

ZcashFoundation Zebra before 6.1.0 contains a resource exhaustion vulnerability that allows unauthenticated peers to degrade block processing by pushing transactions with invalid Orchard proofs without being misbehavior-scored. Attackers can repeatedly push invalid proofs into the shared halo2 batch verifier, forcing honest block proofs onto the slow individual-verification path and slowing block processing roughly sevenfold.

Zebra (zebrad) before 6.2.1 contains an asymmetric resource consumption vulnerability that allows unauthenticated peers to stall block verification by pushing V6 mempool transactions with invalid Halo2 proofs. Attackers can flood the shared unprioritized Halo2 verification queue with zero-fee transactions carrying zero-filled Orchard and Ironwood proofs, causing nodes to fall behind the chain tip.

Zebra before 6.2.1 contains an incomplete cleanup vulnerability that allows unauthenticated peers to block downloading of valid blocks by leaving rejected hashes in SentHashes. Attackers can send a contextually invalid block sharing an honest block's header hash, causing Request::KnownBlock to skip the honest block and keep nodes behind the tip.

ZEBRA, a Zcash node written in Rust, before version 4.5.0 can accept a block that zcashd rejects due to undercounting the P2SH signature-operation counter for scripts containing a disabled opcode. An attacker can exploit this to cause a chain split, affecting network integrity and availability.

Zebra before 6.4.0 contains an uncontrolled resource consumption vulnerability that allows unauthenticated peers to force full proof verification by serving forged block bodies with valid header hashes. Attackers can flip authorizing-only bytes such as a coinbase scriptSig, wasting Sapling, Orchard, and Ironwood proof verification without penalty and stalling sync for 67 seconds.

Zebra versions 2.3.0 through 6.3.1 have a protection mechanism failure that lets unauthenticated peers evade bans because bans and misbehavior scores are keyed on exact IP addresses. Attackers can reconnect from fresh IPv6 addresses in their /64 allocation or flush the 20,000-entry FIFO ban list to restore access for banned peers.

ZcashFoundation Zebra 6.4.0 before 6.4.2 parses version 6 transactions carrying a pre-NU6.3 consensus branch ID, but the size computation during UnminedTx construction treats re-serialization of the Orchard bundle as infallible, so the resulting error trips an expect that aborts zebrad. Unauthenticated peers can send a single pre-handshake tx message to crash the node, and can repeat this after each restart.

Zebra before 4.4.0 contains a consensus divergence vulnerability in V5 transparent signature verification, computing a ZIP-244 digest for SIGHASH_SINGLE inputs lacking corresponding outputs instead of failing. Attackers can craft V5 transactions with fewer outputs than inputs that Zebra accepts and templates via getblocktemplate, producing blocks zcashd rejects.

Zebra before 6.3.0 contains an improper exceptional condition check in ChainSync::obtain_tips that discards valid one-hash FindBlocks responses, falsely reporting close-to-tip status. Peers returning only the next block hash cause a zero-length sync sample, making the /ready endpoint return 200 OK while the node remains behind the tip.

Zebra before 6.1.0 contains an incomplete cleanup vulnerability in the state write task that allows remote unauthenticated peers to stall node synchronization by poisoning parent_error_map. Attackers can deliver a coinbase-malleated block sharing a canonical block's hash before it propagates, causing the next canonical block to be rejected and stalling the node for roughly 2,000 blocks.

Zebra before 6.1.0 contains an incorrect calculation vulnerability in its ZIP-317 block template selector that omits header and transaction-count size from the block budget. Attackers can place valid selectable transactions in a victim miner's mempool to shape templates into oversized blocks, causing rejection and wasted proof-of-work.

The block sync download path in Zebra (zebrad) before 6.3.0 reads a block's height from its unvalidated coinbase scriptSig and drops blocks that appear too far behind the tip before consensus validation, without penalizing the supplying peer. Because V5 transaction IDs exclude the scriptSig, a malicious peer can repeatedly serve a canonical block whose coinbase claims height 1 while keeping the requested hash, delaying the node's discovery of the newest block.

Zebra before 6.3.0 contains a protection mechanism failure that allows unauthenticated peers to evade misbehavior scoring by supplying invalid gossiped blocks. The inbound cleanup step wrongly downcasts RouterError to VerifyBlockError and discards the score, so attackers can repeatedly force block download and Equihash verification without being banned.

Zebra (zebrad) 4.5.0 before 6.3.0 discards which peer supplied the block hashes in FindBlocks responses, then assigns 100 misbehavior points, the ban threshold, to whichever peer serves a requested block more than 50,000 heights above the tip. A remote peer can return real far-ahead hashes to a syncing node so that honest peers get banned, eroding its peer set and raising eclipse risk.

ZEBRA (Zcash node) before version 4.5.0 has a vulnerability allowing an unauthenticated IPv4 peer to deterministically terminate a synced node. By completing a P2P handshake and advertising an invalid mempool transaction, the attacker can trigger an assertion in the code, causing a panic/abort that stops the node. The issue is fixed in version 4.5.0.

ZEBRA prior to 4.5.0 can be terminated by a malicious block producer by placing the same shielded transaction in a non-finalized parent block and its child. The uniqueness assertion is reachable before contextual validation, and release builds use panic=abort, terminating the process.

ZEBRA prior to 4.5.0 can be permanently halted by a consensus-valid block containing a long chain of transparent self-spends. The credit-first ordering can cause the intermediate balance to exceed MAX_MONEY, leading to a panic in release builds. The block is accepted by zcashd, so the halt persists after restart.

ZEBRA prior to 4.5.0 can be slowed down by a malicious P2P peer that answers getblocks/FindBlocks with a small inventory and serves a block with coinbase height far above the local tip. The error is not attributed to the peer, causing cancellation of downloads and a 67-second sync delay. The peer is not scored or disconnected, so it can repeat the attack.

ZEBRA before version 4.5.0 has a vulnerability allowing a remote unauthenticated P2P peer to stall a node by racing an invalid block body against the valid canonical body for the same block header hash. This causes the node to reject the valid body and remain stuck one height behind until restart or reorganization. The issue is fixed in version 4.5.0.

ZEBRA is a Zcash node written in Rust. Prior to 4.5.0, an unauthenticated P2P peer can cause the mempool download pipeline to retain transactions after the RATE_LIMIT_DELAY timeout. This leads to unbounded memory growth and potential node crash.

ZEBRA is a Zcash node written in Rust. Prior to 4.5.0, a chain fork can leave stale Sapling and Orchard note-commitment subtree roots in Zebra state. This can lead to incorrect subtree roots served to consumers like lightwalletd, causing wallet sync failures.

ZEBRA is a Zcash node written in Rust. Prior to 4.5.0, one unauthenticated P2P peer can monopolize all 25 MAX_INBOUND_CONCURRENCY slots in the inbound mempool download pipeline. This can cause honest transactions to be rejected with MempoolError::FullQueue.

ZEBRA is a Zcash node written in Rust. Prior to 4.5.0, an attacker authenticated to an enabled RPC endpoint can terminate zebrad by supplying a getblocktemplate LongPollId with multi-byte UTF-8 characters. This triggers a Rust panic, and release builds use panic=abort, killing the process.

ZEBRA (Zcash node) prior to zebrad 4.3.0 and zebra-consensus 5.0.1 has a logic error in the transaction verification cache. A malicious miner can induce a consensus split by matching a valid transaction's txid with invalid authorization data, causing vulnerable nodes to accept an invalid block.

ZEBRA, a Zcash node written in Rust, prior to zebrad version 4.3.0 and zebra-chain version 6.0.1 contains a vulnerability in transaction processing logic. A remote, unauthenticated attacker can send a specially crafted V5 transaction that passes initial deserialization but fails during transaction ID calculation, causing the node to panic (crash).