Zebra 6.3.0: Sync and Peer-Scoring Security Fixes and New Node Reporting
Today we are releasing Zebra 6.3.0 as a recommended security release. It resolves four security advisories in block synchronization and peer scoring, including a peer-induced delay in tip discovery, a near-tip sync stall, and gaps that let malicious peers get honest peers banned or evade banning, and it hardens inbound ban enforcement. The release also adds a new getdeprecationinfo RPC, new default DNS seeders, and more granular network metrics.
All operators are encouraged to upgrade.
Security Advisories
GHSA-g95h-hw6g-pvgv: Coinbase scriptSig Rewrite Delaying Tip Discovery (High)
A malicious peer could delay a node’s discovery of the newest canonical block by answering a block-download request with a forged body that still matched the requested hash, since rewriting only the coinbase scriptSig (excluded from the V5 transaction ID) leaves the block hash unchanged. Zebra read the forged far-behind height from the unvalidated body and dropped the block as too old before consensus validation, without scoring the peer or re-requesting the hash until the next sync round. Nothing invalid is accepted, so the effect is a transient delay in tip discovery, worst for nodes feeding a mining backend. Zebra now re-requests the hash immediately and penalizes the peer when a block it already holds proves the claimed height wrong. Thanks to @zakura-security, who reported this issue through an OtterSec engagement on the Zakura fork.
GHSA-qhr3-cvch-5fh2: Far-Ahead Block Scoring Enabling Ban Amplification (Medium)
Blocks above the sync lookahead height limit were penalizing the peer that served them, but a FindBlocks response does not record which peer supplied its hashes, so the follow-up block request is routed to an unrelated honest peer. A malicious FindBlocks responder could exploit this to get honest peers scored and banned throughout initial block download, degrading a node’s ability to sync. Zebra no longer scores the serving peer for far-ahead blocks. Thanks to @zakura-security for reporting this issue.
GHSA-8hh2-hrf2-cqf4: Gossiped Invalid Blocks Not Scored (Medium)
Peers that gossiped consensus-invalid blocks were never scored for misbehavior, because the inbound download path classified the resulting verification failure in a way that skipped scoring entirely, so those peers were never banned. Zebra now scores such peers for misbehavior again. Thanks to @evan-forbes for reporting this issue.
GHSA-h8m8-844p-v3m9: Near-Tip Sync Stall on Singleton FindBlocks Responses (Medium)
When a FindBlocks response advertised only a single block hash the node did not already have, Zebra did not download that hash, so a node close to the chain tip could stop advancing and stall its sync. Zebra now downloads a peer’s only unknown block hash from a short FindBlocks response, so near-tip nodes keep following the chain. Thanks to @Maakai123 for originally reporting this issue, and to @ouicate for an independent later report.
Other Security Improvements
Inbound address canonicalization
Inbound connections are now canonicalized when they are accepted, so an IPv4 peer that connects to a dual-stack listener as an IPv4-mapped IPv6 address (::ffff:A.B.C.D) is keyed on its canonical IPv4 address. Previously the mapped address became the peer set key, so a ban issued for that peer’s IPv4 address did not disconnect it while it stayed connected, and the same peer counted twice toward the per-IP inbound connection limit.
Complete ban cleanup in the address book
Banning a misbehaving peer now removes every address book entry for that IP, and a banned IP is never selected as a reconnection candidate. Previously an entry on a different port could survive the ban and occupy the first candidate slot until the node restarted. This caused spurious warnings in the log.
Previously Fixed in Zebra 6.2.1
GHSA-2p4c-3q4q-p463: Uncapped Shielded Verification Cost Stalling Block Verification (High)
Resolved in Zebra 6.2.1; later releases already include it and need no action. (We are only disclosing the advisory now because we were double checking if the fix was thorough.) On networks where NU6.3 (Ironwood) is active, a V6 transaction can carry two Halo2 shielded proofs, but the mempool capped concurrent work by transaction count rather than verification cost, and block and mempool verification shared one unprioritized queue. An unauthenticated peer could flood a node with cheap-to-produce but expensive-to-verify transactions bearing canonically sized invalid proofs, stalling block verification so a constrained node fell behind the chain tip until the flood stopped. Zebra 6.2.1 applies a ZIP-317 fee check before proof verification and disconnects peers that send invalid shielded proofs. Thanks to @craftsoldier for reporting this issue.
New Features
End-of-support reporting
A new getdeprecationinfo RPC returns the block height and estimated time at which this release will halt for end of support, in zcashd’s end_of_service format. The end_of_service object is only present on Mainnet, where end of support is enforced.
New default DNS seeders
seeder.zec.rocks and seeder.testnet.zec.rocks are now included as default DNS seeders, improving peer discovery for new and recovering nodes.
More granular network metrics
Prometheus metrics now separate peer connection attempts and terminal outcomes by network, direction, address family, lifecycle stage, and outcome. Version-message metrics report a bounded, self-reported implementation class without using peer IPs or raw user agents as labels. Peer-set, crawler-handshake, and address-book gauges now include a network label, so Mainnet and Testnet values no longer overwrite each other in processes that run both networks.
Bug Fixes
Funding stream metadata for NU6.1 and later
getblocksubsidy now returns NU6-era funding stream metadata (recipient names and specification URLs) for NU6.1 and later upgrades. Amounts and addresses were never affected.
Monetary base cap enforcement
Zebra now rejects blocks whose total chain value pool balance would exceed MAX_MONEY, enforcing the cap on the total monetary base.
Upgrading
You can get this release from the GitHub release page, from crates.io, or from Docker Hub.
Consumers of the zebra-consensus crate API should note that the transaction verifier has been split into separate block and mempool verifiers: the removed transaction::Request::Mempool and transaction::Response::Mempool variants are replaced by dedicated transaction::MempoolRequest and transaction::MempoolResponse types. This is an internal change with no operator-facing behavior difference, but downstream library users will need to update. See the zebra-consensus changelog for the underlying API split.
Contributors
Thank you to everyone who contributed to this release @arya2, @emersonian, @gustavovalverde, @jiehuo100net, @jvff, @oxarbitrage, @syszery and @upbqdn.
Zebra is the Zcash Foundation’s independent, Rust implementation of a Zcash node.