[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 servers by exhausting memory. A single attacker registers 10,000 unique namespaces, pushing server RAM from 18MB to 28MB. Scale to sybil attacks with hundreds of fake peers, and you hit gigabytes—game over for the process. No authentication blocks this; public rendezvous points, key for peer discovery in P2P networks like IPFS or Ethereum clients, go down easily.

libp2p powers decentralized apps across crypto, file sharing, and beyond. Its rendezvous protocol matches peers via shared namespaces on dedicated servers. These servers store registrations mapping peer IDs to namespaces, expiring after a TTL up to 72 hours. The bug? No cap on registrations per peer. Attackers exploit this by flooding unique namespaces—each capped at 255 bytes but unlimited in number.

Technical Breakdown

The flaw sits in protocols/rendezvous/src/server.rs, inside Registrations::add(). This function uses a BiMap for registrations_for_peer (peer ID to namespaces) and a HashMap for registrations (namespaces to peer lists). Every add spawns a heap-allocated BoxFuture in next_expiry, a FuturesUnordered. One registration: three data structures bloated. Ten thousand: memory balloons.

No max_registrations_per_peer exists in the config. Peers can’t re-register the same namespace, but that’s meaningless—generate endless uniques like flood-00000000 to flood-00009999. Disconnects don’t purge entries; only TTL does, locking memory for days. Tested on libp2p v0.56.1, the server accepts every request without rejection.

Proof of Concept

Reproduce it yourself. First, fire up the server from the repo:

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

Then launch the flooder:

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

The client chains registrations on each Registered confirmation. Server baseline RSS: ~18MB. Mid-flood: ~26MB. After 10k: ~28MB. One peer does that. 100 sybils? ~1GB. 1,000? Instant OOM kill. Screenshots confirm: RSS climbs steadily, all 10k accepted.

Fix is straightforward: Add max_registrations_per_peer to Config, check it before inserting. Reject excess, log abuse. Rust-libp2p projects should patch now—v0.56.1 ships vulnerable.

Why This Hits Hard

Rendezvous servers are public beacons. Clients dial them for discovery when direct DHT bootstrapping fails or scales poorly. Take one offline, and clusters fragment—peers can’t find each other, stalling apps. In crypto, think light clients or mobile wallets relying on libp2p; in IPFS, gateway discovery suffers. Attack cost? Near zero: spin up bots on cheap VPS, no PoW, no stake.

libp2p maintainers flagged this high severity, but exposure is widespread. Rust’s safety nets don’t catch resource DoS like unbounded allocations. Operators: monitor registrations per peer, cap aggressively (say, 100 max), rotate servers. Users: diversify rendezvous points, fall back to Kademlia DHT. This exposes P2P fragility—decentralized doesn’t mean resilient without safeguards.

Broader context: libp2p underpins Polkadot, Filecoin, and more. A 2023 audit wave hit similar issues, yet basics slip. Skeptical take: P2P hype overlooks ops reality. Servers centralize risk; attackers target the linchpin. Deployers, audit your stacks—unbounded inputs are DoS magnets.