# GHSA-h72h-ppcx-998p: Zebra has pre-handshake buffer capacity reservation based on attacker-claimed body length

> Remote attackers can cause resource exhaustion in Zebra nodes by reserving large buffers before handshake, potentially leading to denial of service.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 2 Jul 2026

## What is GHSA-h72h-ppcx-998p?

GHSA-h72h-ppcx-998p is a denial of service vulnerability in zebra-network, published on 2 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official 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.

## Which versions are affected by GHSA-h72h-ppcx-998p?

4 open source packages ship an affected version, including zebra-network and zebrad.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `zebra-network` | crates.io | All versions | 7.0.0 |
| `zebra-network` | crates.io | All versions | 7.0.0 |
| `zebrad` | crates.io | All versions | 4.5.0 |
| `zebrad` | crates.io | All versions | 4.5.0 |

## How do I fix GHSA-h72h-ppcx-998p?

Upgrade zebra-network to 7.0.0 or later.

## Is GHSA-h72h-ppcx-998p being exploited?

There is no known exploitation of GHSA-h72h-ppcx-998p in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-h72h-ppcx-998p and fix it if it is affected.

What it is: GHSA-h72h-ppcx-998p is a denial of service vulnerability in zebra-network, published on 2 Jul 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-h72h-ppcx-998p in the wild and no public exploit code.

Affected packages and fixed versions:
- zebra-network (crates.io): affected all versions; fixed in 7.0.0
- zebra-network (crates.io): affected all versions; fixed in 7.0.0
- zebrad (crates.io): affected all versions; fixed in 4.5.0
- zebrad (crates.io): affected all versions; fixed in 4.5.0

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-h72h-ppcx-998p/ (Markdown: https://insights.sbomify.com/GHSA-h72h-ppcx-998p/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-h72h-ppcx-998p

---
From sbomify Insights: https://insights.sbomify.com/GHSA-h72h-ppcx-998p/
Summaries are generated and may contain mistakes; the official description above is the record.