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

A critical flaw in the libp2p-rendezvous server exposes it to denial-of-service attacks. Any peer can register an unlimited number of unique namespaces, forcing the server to allocate memory indefinitely until it crashes from out-of-memory conditions. Tested on libp2p v0.56.1, a single peer registers 10,000 namespaces and spikes server memory usage from 18 MB to 28 MB resident set size (RSS). Scale to 100 sybil identities, and memory hits 1 GB; 1,000 peers kill the process outright.

This matters because rendezvous servers act as public directories for peer discovery in libp2p networks. Projects like IPFS, Ethereum clients, and Filecoin rely on them to connect peers behind NATs or firewalls. Knocking one offline disrupts discovery for thousands of clients, amplifying downtime across decentralized apps. No authentication protects these servers—attackers need only network access.

Vulnerability Mechanics

The bug sits in protocols/rendezvous/src/server.rs inside the Registrations::add() method. The server stores registrations in three structures:

• registrations_for_peer: A BiMap keyed on (PeerId, Namespace), preventing duplicate namespaces per peer.
• registrations: A HashMap for all active registrations.
• next_expiry: A FuturesUnordered of heap-allocated BoxFutures, one per registration.

Each addition allocates fresh memory. Namespaces validate only by length (max 255 bytes via MAX_NAMESPACE), not count. No max_registrations_per_peer exists in the Config. Registrations linger for up to MAX_TTL of 72 hours, even after peer disconnect. Attackers chain registrations on confirmed Registered events, evading rate limits.

Rust-libp2p powers high-stakes networks: Polkadot for blockchain consensus, OrbitDB for decentralized databases. Public rendezvous points, often hosted on VPS or cloud instances, draw attackers precisely because they broadcast fixed multiaddrs. A 2023 scan by libp2p maintainers found over 500 active rendezvous servers; many run outdated versions vulnerable to this.

Proof of Concept

Reproduce on libp2p v0.56.1 from source. First, launch the server:

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

Then flood it with a client registering namespaces flood-00000000 to flood-00009999:

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

Server accepts all 10,000 without rejection. Monitor RSS via ps aux: baseline 18 MB, mid-flood 26 MB, post-flood 28 MB. Sybil attacks multiply this linearly—cheap VPS spin up fake peers via Tor or proxies.

Skeptically, libp2p’s modular design invites such oversights. Rendezvous prioritizes simplicity over robustness, assuming benign peers. Real-world attacks hit similar P2P services: a 2022 Helium hotspot flaw let sybils spam beacons, crashing validators.

Impact and Mitigation

Any rust-libp2p app deploying a rendezvous server risks outage. Clients fallback to Kademlia DHT, but rendezvous accelerates bootstrap—downtime slows joins by minutes to hours. In crypto networks, this delays transactions or oracle feeds. Public servers, listed in bootstrap lists, become prime targets; private ones fare better but lose utility.

Fix it simply: Add max_registrations_per_peer (say, 100) to Config and check before add(). Enforce global rate limits per PeerId. Expire on disconnect. Upstream merged a patch post-disclosure, but operators must upgrade. Audit your stack—libp2p’s 0.52+ versions fixed related issues, yet this slipped through.

Why care? P2P promises resilience, but central rendezvous chokepoints undermine it. Run your own, cap registrations, or shift to gossipsub. In crypto, where uptime equals revenue, this DoS turns free peer discovery into a liability. Check your nodes now.