Zebra network: Zebra has pre-handshake buffer capacity reservation based on attacker-claimed body length
Affects zebra-networkSource GCVE Database
CVSS 3.7 Low : upgrade to 7.0.0 when convenient.
Data as of 3 Jul 2026, 22:49 UTC
- Patch
- Available – fixed in 7.0.0, 4.5.0
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:LWhat to do
Upgrade zebra-network to 7.0.0; zebrad to 4.5.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| crates.iozebra-network | Affected
| Fixed in
|
| crates.iozebrad | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
AI-suggested
A fix is available that defers large buffer reservations until after handshake completion or caps the reservation size for pre-handshake messages. No workaround is necessary as existing per-IP connection limits, handshake timeouts, and accept rate limits effectively mitigate the practical impact. Users should apply the official fix when available to improve defense-in-depth.
Description
### Am I affected You are affected if: 1. You run `zebrad` up to and including `v4.4.1`. 2. Your node accepts inbound P2P connections (`network.listen_addr` is set, which is the default). ### Summary The P2P codec's `Codec::decode()` method calls `src.reserve(body_len + HEADER_LEN)` after parsing a 24-byte protocol header, using the attacker-claimed `body_len` field. This reserves up to `MAX_PROTOCOL_MESSAGE_LEN` (~2 MiB) of virtual buffer capacity per connection before any body bytes arrive and before the handshake completes. However, `BytesMut::reserve()` sets virtual capacity without committing physical memory pages. The operating system does not allocate physical RAM until bytes are actually written into the buffer. Since the attacker never sends body bytes, the reserved capacity remains uncommitted. Reproduction of the reporter's PoC (256 threads, 30 seconds of sustained connections) showed negligible RSS impact on the Zebra process. Zebra's existing mitigations further constrain the practical attack surface: per-IP connection limits (`max_connections_per_ip = 1`), a per-connection accept rate of approximately one per second, and a 3-second handshake timeout that cleans up idle connections. ### Details At `zebra-network/src/protocol/external/codec.rs:406`, after parsing the 24-byte header and validating the network magic and body length against `MAX_PROTOCOL_MESSAGE_LEN`, the codec calls `src.reserve(body_len + HEADER_LEN)`. The codec is constructed on the bare TCP stream before `negotiate_version()` runs, so the reservation is reachable from any TCP peer that can send 24 bytes. No legitimate Zcash handshake message (`version`, `verack`) is anywhere close to 2 MiB. The codec makes no distinction between pre-handshake and post-handshake message types when sizing the reservation. ### Patches The fix defers large buffer reservations until after the handshake completes, or caps the per-message reservation for pre-handshake messages to what `version`/`verack` actually require. ### Workarounds No workaround is needed. The existing per-IP rate limiting, handshake timeout, and connection limits effectively mitigate the practical impact. ### Impact Minimal. The reservation affects virtual address space only, not physical memory. Zebra's existing connection-management mitigations (per-IP limits, accept rate, handshake timeout) further constrain the attack. The code path is worth cleaning up for defense-in-depth but does not produce a measurable denial-of-service effect. ### Credit Reported by `@ouicate` via a private GitHub Security Advisory submission.
References
- github.com/ZcashFoundation/zebra/security/advisories/GHSA-h72h-ppcx-998p (opens in a new tab)
- github.com/ZcashFoundation/zebra (opens in a new tab)
- github.com/ZcashFoundation/zebra/blob/d4cd662c716382f6397d2a730148025a1ca79fec/zebra-network/src/peer/handshake.rs (opens in a new tab)
- github.com/ZcashFoundation/zebra/blob/d4cd662c716382f6397d2a730148025a1ca79fec/zebra-network/src/protocol/external/codec.rs (opens in a new tab)