We are releasing Zebra 4.3.1 today. This release contains fixes for a number of vulnerabilities, and all node operators are strongly encouraged to upgrade immediately.
In addition to the security fix, this release introduces a Dockerized mining setup, automated checkpoint management, and a number of CI hardening improvements.
Security Advisories
CVE-2026-40880: Transaction Verification Cache Consensus Vulnerability
A logic error in Zebra’s transaction verification cache could have allowed a malicious miner to induce a consensus split between Zebra nodes and the rest of the Zcash network. The root cause was a performance optimization that skipped re-verification of transactions previously accepted into the mempool, without accounting for the fact that a transaction’s validity can be height-dependent.
We removed the optimization entirely, as it was deemed too risky to patch in place. Verification is now always performed in full against the current block height, regardless of prior mempool acceptance.
Thanks to @sangsoo-osec for a thorough advisory submission that identified the lock time issue, and to @shieldedonly for an independently submitted advisory — received while we were already working on the first — that identified additional dimensions of the same vulnerability.
CVE-2026-40881: addr/addrv2 Deserialization Resource Exhaustion
When deserializing addr or addrv2 messages, Zebra would allocate memory for up to 233,000 entries before checking the protocol-specified limit of 1,000. An attacker could exploit this by sending multiple oversized messages across different connections, potentially pushing a Zebra node into an out-of-memory state.
The fix changes the max_allocation() method for the relevant types to return 1000, capping allocation before deserialization begins rather than after.
Thanks to @Zk-nd3r for finding and reporting the issue, and for suggesting the fix.
Consensus Divergence in Transparent Sighash Hash-Type Handling
After a refactoring of Zebra’s transparent transaction verification, a consensus rule restricting valid sighash hash types for V5 transactions was inadvertently dropped. The rule had previously been enforced inside the C++ verification code; when verification was restructured so that only the core check remained in C++ and the rest moved to Rust via callback, the hash-type validation was not carried over. As a result, Zebra nodes could accept transactions that zcashd nodes would correctly reject, creating a consensus split.
A related divergence was also identified in pre-V5 (V4) transactions. zcashd serializes the raw hash_type byte directly into the V4 sighash preimage and only masks it with 0x1f for selection logic, preserving non-canonical bits (e.g. 0x41) in the digest. Zebra instead canonicalized the byte before computing the sighash, producing a different digest. This meant that a V4 transaction signed with a non-canonical hash_type — valid and accepted by zcashd — would be rejected by Zebra due to a sighash mismatch, creating a second consensus split in the opposite direction.
The fix adds the missing hash-type validation for V5 transactions in the Rust callback, and introduces a raw-byte sighash path for V4 transactions that preserves zcashd’s preimage semantics. Both fixes are included in zcash_script 0.4.4 and zcash_transparent 0.6.4.
Our thanks for the initial discovery of this vulnerability go to Alex “Scalar” Sol and also to @sangsoo-osec for a later independently submitted advisory confirming the same vulnerability.
rk Identity Point Panic in Transaction Verification
Orchard transactions include an rk field — a randomized validating key and elliptic curve point. While the Zcash specification permits rk to be the identity value, the orchard crate would panic when encountering it, crashing the node. An attacker could exploit this by submitting a crafted transaction with an identity rk.
The fix, agreed upon with zcashd developers who share the same exposure, disallows the identity rk at the point of transaction parsing. This was considered the safest approach, as fixing it inside the orchard crate would have made the vulnerability public before nodes could be patched. The Zcash specification has been updated accordingly.
Our thanks for the discovery of this vulnerability go to Alex “Scalar” Sol.
Denial of Service via Interrupted JSON-RPC Requests from Authenticated Clients
Zebra’s JSON-RPC HTTP middleware treated a failure to read the incoming HTTP request body as an unrecoverable error, aborting the process rather than returning an error response. A client that disconnected after sending only part of a request body, for example, by resetting the TCP connection mid-transfer, was sufficient to trigger the crash. The vulnerability could be exploited only by authenticated RPC clients. Nodes running the shipped defaults, with RPC bound to localhost and cookie authentication on, were not vulnerable. The fix propagates failures to read the HTTP request body as ordinary error responses, so Zebra now rejects truncated or interrupted requests rather than crashing.
Security Improvements
Supply Chain and License Auditing in CI
CI now runs advisory checks, license compliance scanning, and cargo-vet auditing on every pull request. This ensures that new dependencies are vetted before they land in the codebase, reducing exposure to supply chain vulnerabilities. (#10455)
Updated Security Policy
SECURITY.md has been updated to include a public encryption key, giving security researchers a clear and secure channel for responsible disclosure. (#10460)
Security Advisory Documentation
Past security advisories have been documented in the changelogs, improving the historical record and transparency around Zebra’s security posture. (#10433)
New Features
Dockerized Mining Setup
A Dockerized mining setup has been added to Zebra, making it easier for node operators and developers to run a mining environment alongside their node without managing local dependencies manually. (#10301)
Automated Checkpoint and End-of-Support Height Updates
Checkpoint updates and end-of-support height tracking are now automated in CI. This was previously a manual step, and automating it reduces the risk of human error and keeps Zebra’s checkpoints current with less overhead. (#10459)
Bug Fixes
Proptest Input Data Length Range
An issue with the arbitrary input data length range in property-based tests for chain logic has been fixed, improving the reliability and correctness of the test suite. (#10431)
Other Changes
- PR titles are now required to follow Conventional Commits format, enforced in CI, keeping our changelog and release automation consistent. (#10456)
- The README has been updated to reference the correct
v4.3.0installation tag. (#10432)
Upgrading
We strongly recommend all Zebra node operators upgrade to 4.3.1 as soon as possible, particularly due to the consensus vulnerability 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 malicious forks. You can find the release on GitHub.
Thank You to Our Contributors
This release was made possible by the work of @conradoplg, @gustavovalverde, @mpguerra, @oxarbitrage, @arya2 and @upbqdn. Thank you for your continued contributions to Zebra. We also extend our thanks to ZODL and Shielded Labs for their coordination efforts throughout this release.
Zebra is the Zcash Foundation’s independent, Rust-based implementation of the Zcash protocol. Learn more at github.com/ZcashFoundation/zebra.
