Threat database

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 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.

Zebra versions 2.3.0 up to but not including 6.4.0 have a protection mechanism failure that allows unauthenticated peers to bypass bans. This occurs because bans and misbehavior scores are keyed only on exact IP addresses, enabling attackers to evade bans by reconnecting from new IPv6 addresses within their /64 allocation or by flushing the 20,000-entry FIFO ban list. The vulnerability has a medium severity with a CVSS score of 6.9.

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 before 4.4.0 have a consensus divergence vulnerability related to improper verification of cryptographic signatures in V5 transparent signature verification. Specifically, Zebra incorrectly computes a ZIP-244 digest for SIGHASH_SINGLE inputs that lack corresponding outputs instead of rejecting them. This allows attackers to craft V5 transactions with fewer outputs than inputs that Zebra accepts and templates via getblocktemplate, but which are rejected by zcashd nodes.

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 versions before 6.3.0 have an improper check for exceptional conditions in the ChainSync::obtain_tips function. This flaw causes the node to discard valid one-hash FindBlocks responses, incorrectly reporting that it is close to the blockchain tip. As a result, peers that return only the next block hash cause a zero-length sync sample, making the /ready endpoint return a 200 OK status even though the node is behind the tip.

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.

A reachable assertion vulnerability exists in the getblock RPC method of the Zcash Foundation's Zebra node before version 11.0.0. When called with verbosity level 2 for a side-chain block, the method panics due to an unexpected conversion of a -1 confirmations sentinel value to an unsigned 32-bit integer, causing the node process to abort. This can be triggered remotely by unauthenticated attackers, including via the lightwalletd interface, potentially causing the node to enter a crash loop.

Zebra versions before 6.1.0 have a vulnerability in the state write task that allows remote unauthenticated peers to stall node synchronization. This occurs through poisoning the parent_error_map by delivering a coinbase-malleated block that shares a canonical block's hash prematurely, causing rejection of the next canonical block and stalling the node for about 2,000 blocks.

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 versions before 6.1.0 have a vulnerability in the ZIP-317 block template selector where the calculation of the block size budget incorrectly omits the header and transaction-count size. This allows attackers to insert valid transactions into a miner's mempool to create oversized block templates, which are then rejected, causing wasted proof-of-work.

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.

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.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.