ZEBRA vulnerabilities
12 known CVE vulnerabilities in ZEBRA, translated and rated.
- CVE-2026-52735Critical
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.
- CVE-2026-52829High
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.
- CVE-2026-52739Medium
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.
- CVE-2026-52738Medium
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.
- CVE-2026-52737Medium
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.
- CVE-2026-52736High
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.
- CVE-2026-52734Medium
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.
- CVE-2026-52733Medium
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.
- CVE-2026-52732Medium
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.
- CVE-2026-52731Medium
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.
- CVE-2026-34377High
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.
- CVE-2026-34202High
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).

