[HIGH] Security Advisory: libp2p-rendezvous: Unlimited namespace registrations per peer enables OOM DoS on rendezvous servers (libp2p-rendezvous)

A critical denial-of-service vulnerability in libp2p-rendezvous lets any peer crash public rendezvous servers through memory exhaustion. A single attacker registers thousands of unique namespaces without limit, forcing the server to allocate memory for each one until it runs out of RAM and dies. No authentication blocks this; anyone connected can execute it.

libp2p powers peer-to-peer networking in projects like IPFS, Filecoin, and Polkadot. Its rendezvous protocol helps peers behind NATs or firewalls discover each other via public servers. These servers act as directories: peers register namespaces, and others query them. The flaw lies in the server code from rust-libp2p v0.56.1 and earlier—no cap exists on registrations per peer.

Vulnerability Mechanics

The bug sits in protocols/rendezvous/src/server.rs, specifically Registrations::add(). The storage uses a BiMap keyed on (PeerId, Namespace), preventing duplicate namespaces per peer. But nothing stops a peer from registering 10,000 distinct ones. Each adds entries to:

• registrations_for_peer (BiMap)
• registrations (HashMap)
• next_expiry (FuturesUnordered of heap-allocated BoxFutures)

Namespaces validate only by length—MAX_NAMESPACE = 255 bytes—no count limit. Registrations persist up to MAX_TTL = 72 hours. Disconnecting the peer doesn’t purge them; TTL must expire. Attackers chain registrations on confirmed Registered events, overwhelming the server steadily.

A fix requires adding max_registrations_per_peer to the Config and checking it before insertion. Developers should implement this now, especially for public servers.

Proof of Concept

The PoC, tested on libp2p v0.56.1, confirms the issue. Start the server:

cargo run --manifest-path examples/rendezvous/Cargo.toml --bin rendezvous-example

Then flood it with a client registering 10,000 namespaces like flood-00000000 to flood-00009999:

cargo run --manifest-path examples/rendezvous/Cargo.toml --bin rzv-flood

Server memory (RSS via ps aux):

• Baseline: ~18 MB
• Mid-flood: ~26 MB
• After 10k: ~28 MB

One peer causes a 10 MB spike. 100 sybil identities? Roughly 1 GB. 1,000? Server OOMs instantly. All 10,000 succeeded—no rejections.

Impact and Why It Matters

Public rendezvous servers are fixed, discoverable points—prime DoS targets. Knocking one offline breaks peer discovery for clients relying on it, fragmenting networks. In IPFS, this delays content fetching; in blockchain clients like Substrate, it slows node bootstrapping.

No special privileges needed: connect, flood, done. Sybil attacks amplify trivially with bots or VPSes. libp2p’s growth—used in Ethereum’s devp2p forks, Helium, and more—expands the blast radius. Operators often run lean servers without monitoring, assuming p2p resilience.

This exposes a pattern in decentralized tech: public utilities lack basic resource limits. Fair to say libp2p maintainers move fast, but server-side DoS gets overlooked amid client-focused dev. Check your deployments: if you run a rendezvous point, patch or limit exposure. Networks should diversify servers and add client-side retries.

Bottom line: easy exploit, high disruption. Fix it before attackers notice.