Zebra 4.5.0 Release – Zcash Foundation

We are releasing Zebra 4.5.0 today. This release contains fixes for multiple security vulnerabilities, including one consensus-critical issue, and we strongly encourage all node operators to upgrade immediately. 

The release also adds support for mining to a shielded address.

Security Advisories

GHSA-gf9r-m956-97qx: P2SH Sigop Undercount in Pure-Rust Script Parser (Critical)

Zebra’s pure-Rust transparent script parser incorrectly short-circuited sigop counting when it encountered a disabled opcode inside a P2SH redeem script. The parser treated disabled opcodes as an early termination signal rather than continuing to count subsequent signature operations. This caused Zebra to undercount P2SH sigops against the 20,000-sigop block limit, allowing it to accept blocks that zcashd rejects — a consensus divergence that could lead to a chain split.

Thanks to @samsulselfut for reporting this issue.

GHSA-4m69-67m6-prqp: Stale SentHashes Suppress Valid NU5 Block Retries (High)

Zebra recorded block hashes in a deduplication cache before contextual validation completed. If a malicious peer delivered an alternate NU5 block body with the same header hash but modified authorizing data (which fails contextual validation), the stale cache entry permanently suppressed the valid canonical body. The node would remain stuck at one block below the affected height until restarted. This vulnerability was independently reported by nine separate researchers.

Thanks to @ipwning, @x15-eth, and the other independent reporters for identifying this issue.

GHSA-w834-cf6p-9m9w: Finalized Address Balance Overflow on Consensus-Valid Blocks (High)

The finalized transparent address balance writer processed all newly-created outputs before processing spent outputs within the same block. A consensus-valid block containing a long chain of same-address transparent self-spends could cause the intermediate per-address balance to exceed the maximum money supply during the credit pass, triggering a panic. Because the triggering block is consensus-valid, the panic would recur on restart, permanently halting the node.

Thanks to @sangsoo-osec for reporting this issue.

GHSA-c8w6-x74f-vmg3: z_listunifiedreceivers Panic on Invalid Sapling Receiver (Medium)

The z_listunifiedreceivers RPC handler called .expect() on a fallible Sapling address conversion, assuming that successful Unified Address envelope decoding proved the receiver bytes were semantically valid. A checksum-valid Unified Address containing an invalid Sapling receiver would panic and abort the process. This was the most independently reported vulnerability in this cycle, with six separate researchers finding the same issue.

Thanks to @robustfengbin for the initial report.

GHSA-qv2r-v3mx-f4pf: getblocktemplate LongPollId UTF-8 Boundary Panic (Medium)

The getblocktemplate RPC parameter parser sliced the longpollid string at fixed byte offsets without checking character boundaries. A longpollid containing multi-byte UTF-8 characters at the right length could panic during deserialization, crashing the node.

Thanks to @sangsoo-osec for reporting this issue.

GHSA-4fc2-h7jh-287c: Mempool Queue Saturation via Unauthenticated Peer (Medium)

The mempool download/verification pipeline had a shared 25-slot queue with no per-peer admission limits. A single unauthenticated peer could monopolize all slots, preventing honest peers’ transactions from being admitted. The overload condition was silently absorbed rather than surfaced to the peer connection layer for scoring or disconnection.

Thanks to @dingledropper for reporting this issue.

GHSA-2gf8-q9rr-jq3h: Subtree Root Corruption After Non-Finalized Chain Fork (Medium)

pop_tip() did not revert Sapling and Orchard subtree maps when reverting a tip block. After a non-finalized chain fork, orphaned subtree entries persisted and were eventually written to the finalized RocksDB, causing light wallets to receive incorrect Merkle subtree roots and fail to spend affected notes.

Thanks to @dingledropper for reporting this issue.

GHSA-65jj-fmw8-468q: Mempool cancel_handles Timeout Leak (Medium)

The mempool download pipeline leaked cancel_handles entries when verification timed out, because the timeout error path did not preserve the transaction ID needed for cleanup. This caused monotonic memory growth under sustained mempool verification timeouts.

Thanks to @AnticsDecoded for reporting this issue.

GHSA-gvjc-3w7c-92jx: Sync Restart Poisoning from Single Unauthenticated Peer (Medium)

A malicious peer could answer Zebra's FindBlocks request with a small inventory, then serve a block whose height was far above the victim’s local tip. The resulting error triggered a global sync restart with a 67-second penalty on mainnet, rather than being scoped to the offending peer. The peer was never scored or disconnected. The fix also expands misbehavior scoring to cover contextual validation failures that previously scored zero.

Thanks to @ipwning and @sangsoo-osec for reporting the issues.

GHSA-hhm7-qrv5-h4r6: Repeated Shielded Transaction Assert Panic in Non-Finalized Chain (Medium)

An invalid child block repeating a shielded transaction from its non-finalized parent triggered an assertion panic in the transaction-hash location index before the intended duplicate-nullifier guard could reject the block. A malicious block producer could crash targeted nodes by including a duplicate shielded transaction in a valid-work child block.

Thanks to @Haxatron for reporting this issue.

GHSA-63wg-wjjj-7cp8: IPv4-Mapped Address Misbehavior Panic on Dual-Stack Listeners (Medium)

An address normalization mismatch between the handshake path (which canonicalizes IPv4-mapped IPv6 addresses) and the mempool misbehavior path (which preserves raw transient socket addresses) caused a deterministic assertion panic in the address book on Linux dual-stack configurations. A remote peer could trigger this by advertising an invalid mempool transaction and waiting for the 30-second misbehavior batch flush.

Thanks to @Haxatron for reporting this issue.

GHSA-h72h-ppcx-998p: Pre-Handshake Buffer Capacity Reservation (Low)

The P2P codec reserved buffer capacity based on attacker-claimed body lengths before the handshake completed. The fix caps pre-handshake message body lengths to what version/verack messages actually require.

Thanks to @ouicate for reporting this issue.

GHSA-443g-gwgp-49×4: getblocks/getheaders Locator CPU Amplification (Low)

The getblocks and getheaders codec paths accepted locator vectors up to ~65,535 entries (the generic TrustedPreallocate ceiling) instead of the protocol-spec limit of 101 entries. Each entry required a per-hash chain and database lookup on a blocking-pool thread, creating a CPU amplification vector.

Thanks to @dingledropper for reporting this issue.

New Features

ZIP-213 Support

Zebra now supports ZIP-213 (shielded coinbase outputs to Sapling). (#10048)

Linux TCP Slow-Start Warning

Zebra now warns at startup if Linux TCP slow-start-after-idle is enabled, which can degrade P2P performance. (#10513)

Other Security Improvements

• Capped upfront Vec::with_capacity reservation in zcash_deserialize_external_count so a peer-supplied CompactSize cannot force a large allocation before any element bytes are read (#10563)
• Capped block::Hash::max_allocation at 101 and CountedHeader::max_allocation at 160, matching protocol-level constants (#10570)

Bug Fixes

• Guarded most_recent_by_ip unwrap in the address-book ban path to avoid a panic when max_connections_per_ip > 1 (#10589)
• Propagated transaction value-balance errors in chain_value_pool_change instead of silently dropping them (#10590)
• Solved Rust 1.97 beta clippy lints (#10644)

Other Changes

• Renamed testnet_parameters in network config; use [network.params] instead. The old format is still accepted. (#10051)

Upgrading

We strongly recommend all Zebra node operators upgrade to 4.5.0 as soon as possible, particularly due to the consensus vulnerability and the multiple denial-of-service issues described above. There are no known workarounds — upgrading is the only way to ensure your node remains on the correct chain and is protected against the issues listed in this release. You can find the release on GitHub.

Acknowledgments

This release addresses findings from over 80 security reports received during the ZCG Vulnerability Disclosure Initiative (April–May 2026). We are grateful to all the researchers who participated, including @samsulselfut, @ipwning, @x15-eth, @sangsoo-osec, @robustfengbin, @dingledropper, @AnticsDecoded, @Haxatron, @ouicate, and the team at Least Authority for their AI-assisted audit work. We also thank the many other reporters whose duplicate findings confirmed the severity and breadth of the identified vulnerability classes.

Thank You to Our Contributors

This release was made possible by the work of @ValarDragon, @andres-pcg, @conradoplg, @dingledropper, @evan-forbes, @gustavovalverde, @oxarbitrage, @syszery, @upbqdn, and @zmanian. Thank you for your continued contributions to Zebra.

Zebra is the Zcash Foundation’s independent, Rust-based implementation of the Zcash protocol. Learn more at github.com/ZcashFoundation/zebra.