> For the complete documentation index, see [llms.txt](https://milaforge.gitbook.io/home/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://milaforge.gitbook.io/home/software-engineering/finding-security-vulnerability-in-libp2p.md).

# Finding security Vulnerability in libp2p

How an unbounded pagination state in libp2p rendezvous could allow a remote peer to exhaust server memory.

<p align="center"><strong>When Protocol State Has No Bound: Finding a Remote Memory Exhaustion Vulnerability in libp2p</strong></p>

Network protocols often need temporary state to track requests, pagination, sessions, or other interactions. That state becomes a security problem when an unauthenticated peer can create it without a meaningful bound.

While reviewing the *rendezvous* implementation in Rust's `libp2p`, I identified a case where pagination state could grow without an upper limit, allowing a remote peer to exhaust the server's memory.

The issue was assigned [**CVE-2026-35457**](https://nvd.nist.gov/vuln/detail/CVE-2026-35457) with a CVSS 3.1 score of **8.2 (High)**.

### The mechanism

The rendezvous server keeps pagination state in a map:

```rs
HashMap<Cookie, HashSet<RegistrationId>>
```

When a peer sends a `DISCOVER` request, the server may generate a new pagination cookie and retain it in this state.

The problem was straightforward:

**there was no upper bound or eviction policy for these cookies.**

### The attack

An attacker does not need authentication or malformed protocol messages.

They can repeatedly send valid `DISCOVER` requests:

```
Attacker
   │
   ├── DISCOVER ──→ new pagination state
   ├── DISCOVER ──→ new pagination state
   ├── DISCOVER ──→ new pagination state
   ├── DISCOVER ──→ new pagination state
   │
   └── ...
             ↓
      unbounded server state
             ↓
        memory exhaustion
```

The important property is that the attacker controls the **rate at which server-side state is created**, while the server has no corresponding resource limit.

This turns an apparently harmless pagination mechanism into a resource-exhaustion primitive.

The vulnerability was classified as **CWE-770: Allocation of Resources Without Limits or Throttling**.

### Why this matters

The interesting part is not the `HashMap` itself.

The security boundary is the relationship between:

> **untrusted input → server-side state → resource consumption**

Whenever a network request can create persistent or semi-persistent state, the implementation needs an answer to three questions:

1. **How much state can one peer create?**
2. **How long does that state live?**
3. **What happens when the limit is reached?**

If those questions have no explicit answers, the protocol may contain a resource-exhaustion vulnerability even when every individual request is valid.

### Resolution

The vulnerability affected `libp2p-rendezvous` versions before **0.17.1** and was fixed in **0.17.1**.

### Takeaway

Security review is often less about finding malformed input and more about questioning the assumptions behind otherwise legitimate behavior.

In this case, the critical assumption was that pagination state would remain manageable.

It wasn't bounded.

That was enough to turn a valid protocol operation into a remote memory-exhaustion attack.

**Disclosure:** CVE-2026-35457 · GHSA-v5hw-cv9c-rpg7 · CWE-770 · CVSS 8.2 High.

[Read the Security Advisory](https://github.com/libp2p/rust-libp2p/security/advisories/GHSA-v5hw-cv9c-rpg7)