Listen to this Post
How the mentioned CVE works (technical details, ~20 lines):
The vulnerability resides in the deserialization of `addr` and `addrv2` network messages within Zebra’s codec.rs. When a message arrives, the `zcash_deserialize()` trait method reads a vector of addresses. It determines an upper memory allocation bound via T::max_allocation(). For AddrV1, this bound was computed as `2,097,152 bytes (2 MiB) / 30 bytes` (minimum serialized size of one `AddrV1` entry) = 69,904 entries. For AddrV2, the calculation was `2,097,152 / 9` = 233,016 entries. Zebra would allocate a vector capable of holding up to that many addresses before any validation. Only after full deserialization did the code check the protocol-specified limit of MAX_ADDRS_IN_MESSAGE = 1000. An attacker could craft a single `addr` or `addrv2` message with, for example, 200,000 address entries. The message size remains under 2 MiB due to minimal per‑entry overhead. Zebra would allocate memory for 200,000 addresses (roughly 200,000 30 or 9 bytes plus overhead), then after allocation and parsing, reject the message because it exceeds 1000 entries. However, the memory is already allocated. By sending many such oversized messages over multiple concurrent connections, an attacker can exhaust node memory, causing an out‑of‑memory abort (crash). The fix changes `max_allocation()` to return `1000` directly, preventing the large pre‑deserialization allocation.
dailycve form (3 words max per line):
Platform: Zebra node
Version: Prior 4.3.1
Vulnerability: Resource exhaustion DoS
Severity: Moderate
Date: 2026-04-18
Prediction: Patch 2026-04-15
What Undercode Say:
Analytics (bash commands & codes related to the ):
Check Zebra version
zebrad --version
Simulate memory exhaustion (conceptual - do not run maliciously)
Send crafted addr message with 200,000 entries
Using netcat with a hex payload (truncated example)
echo -e "..." | nc -u target 8233
Monitor memory usage of zebrad process
while true; do ps aux | grep zebrad | awk '{print $6}' ; sleep 1 ; done
Test fix: ensure max_allocation returns 1000
In codec.rs, verify change:
grep -A5 "fn max_allocation" zebra-network/src/codec.rs
Exploit:
Send multiple `addr` or `addrv2` messages with >1000 entries (e.g., 200,000 each) over different TCP connections to a Zebra node pre‑4.3.1. Each message stays under 2 MiB, triggers allocation of huge vector, then fails the limit check but leaves memory allocated. Repeated across connections → OOM crash.
Protection from this CVE
Upgrade to Zebra version 4.3.1 or later immediately. No workarounds exist. The patch enforces the 1000‑entry limit before memory allocation.
Impact:
Denial of Service – remote attacker crashes any vulnerable Zebra node, disrupting network participation and Zcash blockchain sync.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
