Zebra 4.4.0: Important Safety Fixes

We’re releasing Zebra 4.4.0 at present. This launch accommodates 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 through 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 weak as a result of there was no per-connection fee restrict on inv messages. A single connection might ship sufficient sequential inv messages with pretend block hashes to fill the complete gossip obtain queue in underneath a millisecond, and the FullQueue return worth was silently ignored. The syncer backup path could possibly 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 in opposition to the 20,000-sigop block restrict, permitting it to just accept blocks that zcashd rejects. Two distinct undercounts had been recognized:

• Coinbase sigops. zcashd consists of the coinbase enter’s scriptSig in its sigop rely. Zebra skipped the coinbase enter totally, and as much as ~98 sigops could possibly be hidden contained in the coinbase scriptSig with out being charged in opposition to the block restrict.
• Mixture P2SH sigops. zcashd parses every P2SH enter’s redeem script and sums these sigops into the block-wide whole. Zebra computed P2SH sigops solely in mempool transactions and by no means gathered them throughout block validation. A block whose mixture redeem-script sigops exceed 20,000 can be accepted by Zebra and rejected by zcashd.

The repair provides coinbase scriptSig to the legacy sigop iterator, introduces a shared p2sh_sigop_count operate 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 problem.

GHSA-gq4h-3grw-2rhv: Consensus Divergence in Clear Sighash Hash-Sort Dealing with resulting from Stale Buffer

The repair for a earlier sighash advisory (GHSA-8m29-fpq5-89jj) launched a separate problem resulting from inadequate error dealing with when the sighash hash kind is invalid. Zebra’s clear script verification calls Bitcoin Script verification code in C++ by way of a overseas operate interface (FFI), with a Rust callback that computes the sighash. The earlier repair accurately returned None for undefined hash varieties, 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 establishing 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 in opposition to 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 problem.

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 underneath ZIP-244; in Zebra, the sighash engine computed a digest for the missing-output case slightly than failing.

We don’t contemplate this a virtually exploitable safety problem: the state of affairs requires an attacker to each submit a malformed transaction by way of 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’ve got added an specific pre-check that rejects these transactions, matching zcashd‘s conduct and shutting the divergence. (#10510)

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

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

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

• headers message obtain cap. The CountedHeader vector was deserialized through 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 resolution size. The equihash resolution was decoded as a generic Vec and solely checked in opposition to the consensus dimension (1,344 bytes on mainnet) afterwards. A single fixed-size header area could possibly be inflated to almost the total block-size ceiling earlier than rejection.
• Sapling spend vectors in coinbase transactions. V5 spend_prefixes and V4 shielded_spends had 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 rely 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 supposed and precise limits is critical 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 customers as a substitute of backpressuring the server, and reduces the per-stream buffer from 4,000 to 64 messages. Be aware: gRPC subscribers that fall behind are actually dropped as a substitute of backpressuring the server. Properly-behaved purchasers are unaffected.

RPC Request Physique Measurement Restrict

The RPC compatibility middleware learn, parsed, and re-serialized the total HTTP request physique earlier than making use of any native dimension cap. The repair bounds the HTTP request physique through 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, probably permitting different native customers to learn it on multi-user techniques. 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 Discipline in getblock Response

The getblock RPC response now consists of 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 method to observe and catch efficiency regressions throughout releases. (#10444)

Sentry Atmosphere Alignment

Sentry CI metadata and surroundings 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 newest 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 doable, notably as a result of consensus vulnerabilities described above. There are not any identified workarounds — upgrading is the one manner to make sure your node stays on the proper chain and is protected in opposition to the problems listed on this launch. Yow will discover the discharge on GitHub.

Thank You to Our Contributors

This launch was made doable by the work of @alchemydc, @arya2, @conradoplg, @daira, @gustavovalverde, @mpguerra, @oxarbitrage, @schell, and @upbqdn. Thanks in your continued contributions to Zebra.

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