Zebra 4.4.0: Vital Safety Fixes

We’re releasing Zebra 4.4.0 right this moment. This launch comprises fixes for a number of safety vulnerabilities, together with a number of consensus-critical points, and we strongly encourage all node operators to improve instantly.

Safety Advisories

GHSA-28xj-328h-72vm: Everlasting Block Discovery Halt by way of Gossip Queue Saturation + Syncer Poisoning

Zebra’s block discovery pipeline contained a composite denial-of-service vulnerability that allowed a distant attacker to completely halt all new block discovery on a focused node. The assault exploited three impartial weaknesses within the gossip, syncer, and obtain subsystems — all exercisable from a single TCP connection — to create a monotonically rising block deficit that by no means self-heals.

The gossip path was susceptible as a result of there was no per-connection charge restrict on inv messages. A single connection might ship sufficient sequential inv messages with pretend block hashes to fill your entire gossip obtain queue in below a millisecond, and the FullQueue return worth was silently ignored. The syncer backup path might be degraded by responding with empty inv to FindBlocks requests (legitimate protocol, zero misbehavior penalty) and with NotFound to dam obtain requests. The assault produced zero misbehavior rating, zero bans, and 0 disconnections.

The repair drops connections that ship empty responses to FindBlocks and FindHeaders messages, stopping attackers from degrading the syncer path with out consequence.

GHSA-jv4h-j224-23cc: Consensus Block Sigops Undercount

Zebra’s block validator undercounted clear signature operations towards the 20,000-sigop block restrict, permitting it to just accept blocks that zcashd rejects. Two distinct undercounts have been recognized:

• Coinbase sigops. zcashd contains the coinbase enter’s scriptSig in its sigop depend. Zebra skipped the coinbase enter completely, and as much as ~98 sigops might be hidden contained in the coinbase scriptSig with out being charged towards the block restrict.
• Combination P2SH sigops. zcashd parses every P2SH enter’s redeem script and sums these sigops into the block-wide complete. Zebra computed P2SH sigops solely in mempool transactions and by no means collected them throughout block validation. A block whose mixture redeem-script sigops exceed 20,000 could be accepted by Zebra and rejected by zcashd.

The repair provides coinbase scriptSig to the legacy sigop iterator, introduces a shared p2sh_sigop_count perform that mirrors zcashd‘s GetP2SHSigOpCount, and accumulates each legacy and P2SH sigops within the block-validation path.

Due to sangsoo-osec for locating and reporting this challenge.

GHSA-gq4h-3grw-2rhv: Consensus Divergence in Clear Sighash Hash-Kind Dealing with because of Stale Buffer

The repair for a earlier sighash advisory (GHSA-8m29-fpq5-89jj) launched a separate challenge because of inadequate error dealing with when the sighash hash kind is invalid. Zebra’s clear script verification calls Bitcoin Script verification code in C++ by a overseas perform interface (FFI), with a Rust callback that computes the sighash. The earlier repair accurately returned None for undefined hash sorts, however the FFI bridge solely writes to the C++ sighash buffer when the callback returns Some, and the C++ checker reads that buffer unconditionally — so the failure sign was misplaced.

An attacker might exploit this by setting up a clear output spent by a script that runs a sound OP_CHECKSIGVERIFY instantly earlier than an OP_CHECKSIG with an undefined hash kind. The primary opcode primes the C++ sighash buffer with a sound digest; the second causes Zebra’s callback to return None whereas the C++ checker verifies the invalid signature towards the stale digest. Zebra would settle for the spend whereas zcashd would reject it, making a consensus break up.

The repair fills the sighash output buffer with random bytes on validation failure, which makes signature verification fail as anticipated with overwhelming likelihood. This can be a workaround that avoids a breaking launch of the zcash_script crate; a future launch will propagate the error accurately for a direct repair.

Due to sangsoo-osec for locating and reporting this challenge.

GHSA-cwfq-rfcr-8hmp: Clear SIGHASH_SINGLE Corresponding-Output Dealing with

A divergence between Zebra and zcashd was reported in how SIGHASH_SINGLE is dealt with for V5 clear transactions when an enter index has no corresponding output. In zcashd, this case triggers a script failure below ZIP-244; in Zebra, the sighash engine computed a digest for the missing-output case moderately than failing.

We don’t take into account this a virtually exploitable safety challenge: the state of affairs requires an attacker to each submit a malformed transaction by Zebra’s mempool and have an exterior miner embrace it in a block — a series of occasions with no financial incentive that has by no means occurred on mainnet. Nonetheless, we now have added an specific pre-check that rejects these transactions, matching zcashd‘s habits and shutting the divergence. (#10510)

Due to sangsoo-osec and defuse for locating and reporting this challenge.

GHSA-438q-jx8f-cccv: Allocation Amplification in Inbound Community Deserializers

A number of inbound deserialization paths in Zebra allotted buffers sized towards generic transport or block-size ceilings earlier than the tighter protocol or consensus limits have been enforced. An unauthenticated or post-handshake peer might power the node to preallocate and parse orders of magnitude extra knowledge than the protocol meant, amplifying per-message reminiscence and parse price. 4 vectors have been recognized:

• headers message obtain cap. The CountedHeader vector was deserialized by way of the generic TrustedPreallocate path, permitting as much as ~1,409 entries per message. The protocol ceiling of 160 was solely enforced on the ship aspect, creating an ~8.8× preallocation hole on obtain. This was reachable earlier than the model handshake accomplished.
• Equihash answer size. The equihash answer was decoded as a generic Vec and solely checked towards the consensus dimension (1,344 bytes on mainnet) afterwards. A single fixed-size header area might be inflated to almost the complete block-size ceiling earlier than rejection.
• Sapling spend vectors in coinbase transactions. V5 spend_prefixes and V4 shielded_spends have been allotted with block-size-derived ceilings (~5,681 / ~5,208 entries) earlier than the consensus rule that coinbase transactions have zero Sapling spends was enforced within the verifier. The repair reads the Sapling spend depend and rejects coinbase transactions with any spends earlier than allocating the spend vector.
• Coinbase script bytes. The coinbase script was learn as a generic Vec as much as the message-size cap earlier than implementing the consensus rule that coinbase scripts are between 2 and 100 bytes.

Every particular person case is bounded by the two MiB transport ceiling or the block-size cap, so no single message causes unbounded allocation, however the cumulative hole between meant and precise limits is important and stackable throughout concurrent connections. All 4 vectors have been mounted by capping allocations to the protocol-specified limits earlier than deserialization begins.

Due to Zk-nd3r for locating and reporting these points.

Safety Enhancements

Indexer gRPC Server Useful resource Limits

The indexer gRPC server had no connection or subscription cap, and used a 4,000-message per-stream queue with full block payloads. The repair switches indexer streams to make use of try_send, which drops gradual shoppers as an alternative of backpressuring the server, and reduces the per-stream buffer from 4,000 to 64 messages. Observe: gRPC subscribers that fall behind at the moment are dropped as an alternative of backpressuring the server. Properly-behaved shoppers are unaffected.

RPC Request Physique Dimension Restrict

The RPC compatibility middleware learn, parsed, and re-serialized the complete HTTP request physique earlier than making use of any native dimension cap. The repair bounds the HTTP request physique by way of http_body_util::Restricted earlier than allocation, with the restrict derived from MAX_BLOCK_BYTES to accommodate submitblock.

getrawtransaction Block Hash Validation Race

A TOCTOU race situation existed in getrawtransaction between block hash validation and txid lookup throughout chain forks, which might return incorrect outcomes. The repair reuses the caller-provided block hash and its best-chain flag from the preliminary question, avoiding a 3rd state lookup that might race with a reorg.

RPC Auth Cookie File Permissions

The RPC authentication cookie file was written with out specific 0600 permissions, doubtlessly permitting different native customers to learn it on multi-user methods. The repair units restrictive file permissions on the cookie file at creation time on Unix, and in addition rejects symlinks on the cookie path.

Due to Zk-nd3r for locating and reporting the 4 points above.

New Options

nTx Subject in getblock Response

The getblock RPC response now contains the nTx area, reporting the variety of transactions in a block. This improves compatibility with downstream tooling that expects this area. (#10498)

Criterion Benchmark Suite

A Criterion-based benchmark suite and CI workflow have been added, giving the workforce a scientific option to observe and catch efficiency regressions throughout releases. (#10444)

Sentry Atmosphere Alignment

Sentry CI metadata and setting tagging have been aligned, enhancing how crash and error studies are categorized throughout improvement, staging, and manufacturing deployments. (#10490)

Bug Fixes

getrawtransaction Confirmations

A bug within the getrawtransaction RPC that returned incorrect affirmation counts has been mounted. (#10507)

Dependency Updates

librustzcash

The whole librustzcash dependency stack has been migrated to the most recent model. This replaces the yanked core2 crate with corez 0.1.1, clearing the RUSTSEC-2026-0105 advisory. (#10522)

Different Modifications

• Remaining Groth16 proof verification abstractions have been faraway from zebra-consensus, finishing the cleanup after the Sapling verifier migration. (#10436)
• cargo-vet configuration has been mounted to run accurately after releases. (#10504)

Upgrading

We strongly advocate all Zebra node operators improve to 4.4.0 as quickly as attainable, significantly because of the consensus vulnerabilities described above. There are not any recognized workarounds — upgrading is the one manner to make sure your node stays on the right chain and is protected towards the problems listed on this launch. Yow will discover the discharge on GitHub.

Thank You to Our Contributors

This launch was made attainable by the work of @alchemydc, @arya2, @conradoplg, @daira, @gustavovalverde, @mpguerra, @oxarbitrage, @schell, and @upbqdn. Thanks on 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.