CVE-2026-40881: 
Rust vulnerability analysis and mitigation

CVE-2026-40881 is an addr/addrv2 deserialization resource exhaustion vulnerability in Zebra, the Zcash Foundation's Rust-based Zcash node implementation. During deserialization of addr or addrv2 peer address messages, Zebra allocates memory for up to 233,016 entries (derived from the 2 MiB message size limit) before enforcing the protocol-specified maximum of 1,000 entries, enabling unauthenticated remote attackers to trigger out-of-memory crashes. All versions of zebrad prior to 4.3.1 and zebra-network prior to 5.0.1 are affected. The vulnerability was published on April 17–18, 2026, with a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 6.3 (Medium) (GitHub Advisory, Zebra Advisory).

The root cause is CWE-770 (Allocation of Resources Without Limits or Throttling) in the read_addr/addrv2 functions within codec.rs. The zcash_deserialize() trait method uses T::max_allocation() as an upper bound for vector deserialization, which was incorrectly derived by dividing the 2 MiB message size limit by the minimum serialized size of one entry — yielding 69,904 for AddrV1 (2,097,152 / 30) and 233,016 for AddrV2 (2,097,152 / 9). The MAX_ADDRS_IN_MESSAGE = 1000 limit was only checked after full deserialization, meaning the oversized memory allocation had already occurred. An attacker can exploit this by crafting addr or addrv2 messages with a large number of entries and submitting them across multiple simultaneous connections to exhaust available memory (GitHub Advisory, Zebra Advisory).

Successful exploitation results in out-of-memory aborts that crash the Zebra node process, causing a denial of service with high availability impact. There is no confidentiality or integrity impact — the vulnerability is purely a DoS vector. Any publicly reachable Zebra node running a vulnerable version is within scope, and repeated exploitation across multiple connections can sustain the outage, potentially disrupting Zcash network participation for affected node operators (GitHub Advisory).

No public proof-of-concept exploit code or in-the-wild exploitation has been observed as of the time of reporting (Feedly). The vulnerability is unauthenticated and requires no user interaction, but the CVSS v4.0 metric notes that attack requirements are "Present," reflecting that the attacker must be able to establish network connections to the target node. The EPSS score is approximately 0.042% (19th percentile), indicating a low near-term exploitation probability. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. No threat actor attribution has been reported.

1. Reconnaissance: Identify publicly reachable Zebra nodes running versions prior to 4.3.1 using network scanning tools (e.g., Shodan, Censys) targeting the default Zcash P2P port (8233).
2. Establish connections: Open multiple simultaneous TCP connections to the target Zebra node's P2P port to maximize memory pressure across concurrent deserialization operations.
3. Craft malicious messages: Construct addr or addrv2 P2P messages containing a large number of address entries — up to the deserialization ceiling of ~69,904 (AddrV1) or ~233,016 (AddrV2) entries — within the 2 MiB message size limit.
4. Send messages: Transmit the crafted messages over each established connection. Zebra will allocate memory for the full oversized vector during deserialization before reaching the 1,000-entry validation check.
5. Trigger OOM crash: Repeat across multiple connections to accumulate memory allocations, exhausting available system memory and causing Zebra to abort with an out-of-memory error, crashing the node (GitHub Advisory, Zebra Advisory).

• Network: Unusually high number of simultaneous inbound P2P connections to the Zebra node on port 8233 from one or more source IPs; large addr/addrv2 messages (approaching 2 MiB) observed in network traffic captures.
• Logs: Zebra process logs showing repeated deserialization of oversized address vectors followed by abrupt termination; OS-level out-of-memory (OOM) killer log entries (e.g., Linux dmesg showing zebrad killed by OOM killer).
• Process: Sudden termination of the zebrad process without a graceful shutdown signal; rapid respawn cycles if a process supervisor (e.g., systemd) is configured to restart the service.
• System: Spike in memory consumption visible in system monitoring tools (e.g., top, htop, Prometheus metrics) immediately preceding the crash.

The Zcash Foundation has released fixed versions: zebrad 4.3.1 and zebra-network 5.0.1. The fix modifies the max_allocation() method for the relevant address types to return 1,000, enforcing the protocol limit before deserialization occurs and preventing oversized memory allocation. There are no known configuration-based workarounds — the vendor explicitly states that upgrading is the only remediation. As interim measures, operators should implement network-level rate limiting and connection limits to restrict concurrent inbound connections, and consider restricting P2P access to trusted peers until the upgrade is applied (GitHub Advisory, Zebra Advisory, Vendor Blog).

The Zcash Foundation published a blog post announcing the Zebra 4.3.1 release, highlighting the security fix alongside other improvements such as dockerized mining and CI hardening (Vendor Blog). The vulnerability was credited to researcher @Zk-nd3r for discovery and reporting, with remediation developed by oxarbitrage and reviewed by conradoplg, coordinated by mpguerra (GitHub Advisory). No significant broader media coverage or notable community controversy has been observed beyond standard vulnerability database aggregation.