CVE-2026-40881
MEDIUM
GHSA-xr93-pcq3-pxf8
Severity by source
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Primary rating from GitHub Advisory · only source for this CVE.
CVSS VectorGitHub Advisory
CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:L/SC:N/SI:N/SA:L/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Lifecycle Timeline
5DescriptionGitHub Advisory
CVE-2026-40881: addr/addrv2 Deserialization Resource Exhaustion
Summary
When deserializing addr or addrv2 messages, which contain vectors of addresses, Zebra would fully deserialize them up to a maximum length (over 233,000) that was derived from the 2 MiB message size limit. This is much larger than the actual limit of 1,000 messages from the specification. Zebra would eventually check that limit but, at that point, the memory for the larger vector was already allocated. An attacker could cause out-of-memory aborts in Zebra by sending multiple such messages over different connections.
Severity
Moderate - This is a Denial of Service Vulnerability that could allow an attacker to crash a Zebra node.
Affected Versions
All Zebra versions prior to version 4.3.1.
Description
The vulnerability exists in the read_addr/addrv2 functions in codec.rs. It deserializes a vector of addresses with the zcash_deserialize() trait method, which uses as a upper bound the result of T::max_allocation(). For theses types, it was derived from dividing the max message size (2 MiB) by the minimum serialized size of one entry. For AddrV1: 2_097_152 / 30 = 69,904. For AddrV2: 2_097_152 / 9 = 233,016. Only after deserialization was the MAX_ADDRS_IN_MESSAGE = 1000 limit checked.
An attacker could exploit this by:
- Creating
addroraddrv2messages with a large number of entries. - Submitting them to a Zebra node, possibly through multiple connections, to attempt to get Zebra into an out-of-memory state.
Impact
Denial of Service
- Attack Vector: Network.
- Effect: Zebra node crash.
- Scope: Any impacted Zebra node.
Fixed Versions
This issue is fixed in Zebra 4.3.1.
The fix changes the max_allocation() method for the relevant types to return 1,000, thus blocking larger values prior to deserialization.
Mitigation
Users should upgrade to Zebra 4.3.1 or later immediately.
There are no known workarounds for this issue. Immediate upgrade is the only way to ensure the node remains not vulnerable to the denial of service attack.
Credits
Thanks @Zk-nd3r for finding and reporting the issue, and suggesting the fix.
AnalysisAI
Zebra cryptocurrency node prior to version 4.3.1 allocates excessive memory (up to 233,016 addresses) when deserializing addr/addrv2 protocol messages, even though the specification limits messages to 1,000 addresses. An attacker can trigger out-of-memory crashes by sending multiple oversized address messages over different connections. This is a network-accessible denial of service vulnerability affecting all Zebra versions before 4.3.1, with no public exploit code identified but straightforward to execute given the protocol specification.
Technical ContextAI
Zebra is a Zcash full node implementation written in Rust. The vulnerability exists in the deserialization logic for Bitcoin/Zcash protocol messages addr (IPv4/IPv6 addresses) and addrv2 (extended address format). The affected code in codec.rs uses the zcash_deserialize() trait, which respects a max_allocation() limit derived from the 2 MiB protocol message size limit. For AddrV1, this calculated to 2,097,152 bytes ÷ 30 bytes per address = 69,904 addresses; for AddrV2, it calculated to 2,097,152 ÷ 9 = 233,016 addresses. This is a classic deserialization resource exhaustion pattern (CWE-770) where the pre-allocation size check occurs before the semantic validation check. The fix reduces max_allocation() to return 1,000 for these types, enforcing the specification limit prior to memory allocation rather than after.
RemediationAI
Upgrade Zebra immediately to version 4.3.1 or later. The patch modifies the max_allocation() method for addr/addrv2 message types to return 1,000 (the specification limit) instead of the calculated 2 MiB-derived limit, preventing excessive pre-allocation. Users running Zebra nodes should apply this upgrade without delay by updating their Rust dependencies or container images to pull the patched version. The Zcash Foundation has stated there are no known workarounds; the only mitigation is to upgrade. For users unable to immediately patch, temporary network isolation (restricting connections to trusted peers only, or operating behind a strict firewall with rate-limiting on peer connections) could reduce exposure, but this significantly impacts node functionality and peer participation in the Zcash network. The recommended approach is immediate upgrade, as the patch is non-breaking and directly addresses the root cause. Patch availability confirmed in the official GitHub Security Advisory and release notes.
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today