Zebra 4.5.0 Launch – Zcash Basis

We’re releasing Zebra 4.5.0 in the present day. This launch incorporates fixes for a number of safety vulnerabilities, together with one consensus-critical problem, and we strongly encourage all node operators to improve instantly. 

The discharge additionally provides help for mining to a shielded handle.

Safety Advisories

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

Zebra’s pure-Rust clear script parser incorrectly short-circuited sigop counting when it encountered a disabled opcode inside a P2SH redeem script. The parser handled disabled opcodes as an early termination sign moderately than persevering with to depend subsequent signature operations. This induced Zebra to undercount P2SH sigops in opposition to the 20,000-sigop block restrict, permitting it to simply accept blocks that zcashd rejects — a consensus divergence that would result in a series break up.

Due to @samsulselfut for reporting this problem.

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

Zebra recorded block hashes in a deduplication cache earlier than contextual validation accomplished. If a malicious peer delivered an alternate NU5 block physique with the identical header hash however modified authorizing knowledge (which fails contextual validation), the stale cache entry completely suppressed the legitimate canonical physique. The node would stay caught at one block under the affected top till restarted. This vulnerability was independently reported by 9 separate researchers.

Due to @ipwning, @x15-eth, and the opposite impartial reporters for figuring out this problem.

GHSA-w834-cf6p-9m9w: Finalized Deal with Steadiness Overflow on Consensus-Legitimate Blocks (Excessive)

The finalized clear handle stability author processed all newly-created outputs earlier than processing spent outputs inside the similar block. A consensus-valid block containing a protracted chain of same-address clear self-spends may trigger the intermediate per-address stability to exceed the utmost cash provide in the course of the credit score cross, triggering a panic. As a result of the triggering block is consensus-valid, the panic would recur on restart, completely halting the node.

Due to @sangsoo-osec for reporting this problem.

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

The z_listunifiedreceivers RPC handler referred to as .count on() on a fallible Sapling handle conversion, assuming that profitable Unified Deal with envelope decoding proved the receiver bytes have been semantically legitimate. A checksum-valid Unified Deal with containing an invalid Sapling receiver would panic and abort the method. This was probably the most independently reported vulnerability on this cycle, with six separate researchers discovering the identical problem.

Due to @robustfengbin for the preliminary report.

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

The getblocktemplate RPC parameter parser sliced the longpollid string at fastened byte offsets with out checking character boundaries. A longpollid containing multi-byte UTF-8 characters on the proper size may panic throughout deserialization, crashing the node.

Due to @sangsoo-osec for reporting this problem.

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

The mempool obtain/verification pipeline had a shared 25-slot queue with no per-peer admission limits. A single unauthenticated peer may monopolize all slots, stopping trustworthy friends’ transactions from being admitted. The overload situation was silently absorbed moderately than surfaced to the peer connection layer for scoring or disconnection.

Due to @dingledropper for reporting this problem.

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

pop_tip() didn’t revert Sapling and Orchard subtree maps when reverting a tip block. After a non-finalized chain fork, orphaned subtree entries continued and have been ultimately written to the finalized RocksDB, inflicting mild wallets to obtain incorrect Merkle subtree roots and fail to spend affected notes.

Due to @dingledropper for reporting this problem.

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

The mempool obtain pipeline leaked cancel_handles entries when verification timed out, as a result of the timeout error path didn’t protect the transaction ID wanted for cleanup. This induced monotonic reminiscence progress below sustained mempool verification timeouts.

Due to @AnticsDecoded for reporting this problem.

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

A malicious peer may reply Zebra's FindBlocks request with a small stock, then serve a block whose top was far above the sufferer’s native tip. The ensuing error triggered a worldwide sync restart with a 67-second penalty on mainnet, moderately than being scoped to the offending peer. The peer was by no means scored or disconnected. The repair additionally expands misbehavior scoring to cowl contextual validation failures that beforehand scored zero.

Due to @ipwning and @sangsoo-osec for reporting the problems.

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

An invalid little one block repeating a shielded transaction from its non-finalized mum or dad triggered an assertion panic within the transaction-hash location index earlier than the supposed duplicate-nullifier guard may reject the block. A malicious block producer may crash focused nodes by together with a replica shielded transaction in a valid-work little one block.

Due to @Haxatron for reporting this problem.

GHSA-63wg-wjjj-7cp8: IPv4-Mapped Deal with Misbehavior Panic on Twin-Stack Listeners (Medium)

An handle normalization mismatch between the handshake path (which canonicalizes IPv4-mapped IPv6 addresses) and the mempool misbehavior path (which preserves uncooked transient socket addresses) induced a deterministic assertion panic within the handle e book on Linux dual-stack configurations. A distant peer may set off this by promoting an invalid mempool transaction and ready for the 30-second misbehavior batch flush.

Due to @Haxatron for reporting this problem.

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

The P2P codec reserved buffer capability primarily based on attacker-claimed physique lengths earlier than the handshake accomplished. The repair caps pre-handshake message physique lengths to what model/verack messages truly require.

Due to @ouicate for reporting this problem.

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

The getblocks and getheaders codec paths accepted locator vectors as much as ~65,535 entries (the generic TrustedPreallocate ceiling) as a substitute of the protocol-spec restrict of 101 entries. Every entry required a per-hash chain and database lookup on a blocking-pool thread, making a CPU amplification vector.

Due to @dingledropper for reporting this problem.

New Options

ZIP-213 Assist

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

Linux TCP Sluggish-Begin Warning

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

Different Safety Enhancements

• Capped upfront Vec::with_capacity reservation in zcash_deserialize_external_count so a peer-supplied CompactSize can not pressure a big allocation earlier than any aspect bytes are learn (#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 within the address-book ban path to keep away from a panic when max_connections_per_ip > 1 (#10589)
• Propagated transaction value-balance errors in chain_value_pool_change as a substitute of silently dropping them (#10590)
• Solved Rust 1.97 beta clippy lints (#10644)

Different Adjustments

• Renamed testnet_parameters in community config; use [network.params] as a substitute. The outdated format remains to be accepted. (#10051)

Upgrading

We strongly advocate all Zebra node operators improve to 4.5.0 as quickly as potential, notably because of the consensus vulnerability and the a number of denial-of-service points described above. There are not any recognized workarounds — upgrading is the one means to make sure your node stays on the proper chain and is protected in opposition to the problems listed on this launch. You could find the discharge on GitHub.

Acknowledgments

This launch addresses findings from over 80 safety reviews obtained in the course of the ZCG Vulnerability Disclosure Initiative (April–Could 2026). We’re grateful to all of the researchers who participated, together with @samsulselfut, @ipwning, @x15-eth, @sangsoo-osec, @robustfengbin, @dingledropper, @AnticsDecoded, @Haxatron, @ouicate, and the crew at Least Authority for his or her AI-assisted audit work. We additionally thank the numerous different reporters whose duplicate findings confirmed the severity and breadth of the recognized vulnerability lessons.

Thank You to Our Contributors

This launch was made potential by the work of @ValarDragon, @andres-pcg, @conradoplg, @dingledropper, @evan-forbes, @gustavovalverde, @oxarbitrage, @syszery, @upbqdn, and @zmanian. Thanks to your continued contributions to Zebra.

Zebra is the Zcash Basis’s impartial, Rust-based implementation of the Zcash protocol. Be taught extra at github.com/ZcashFoundation/zebra.