PT-2026-30324 · Crates.Io · Libp2P-Rendezvous

Published

2026-04-04

·

Updated

2026-04-04

·

CVE-2026-35405

CVSS v3.1

7.5

High

AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

Summary

Thelibp2p-rendezvous server has no limit on how many namespaces a single peer can register. A malicious peer can repeatedly register unique namespaces in a loop, and the server accepts the requests, allocating memory for each registration without pushback. If an attacker continues submitting malicous requests for long enough, (or with multiple sybil peers) the server process crashes due to OOM.
No auth is required; therefore, any peer on the network can do this.

Details

the bug is in Registrations::add() inside protocols/rendezvous/src/server.rs.
the store uses a BiMap keyed on (PeerId, Namespace) so yes, a peer can't register the same namespace twice. but there's nothing stopping it from registering 10,000 different namespaces. each unique one gets its own entry in:
  • registrations for peer (BiMap)
  • registrations (HashMap)
  • next expiry (FuturesUnordered a new heap-allocated BoxFuture per registration)
namespace strings are only validated for length (MAX NAMESPACE = 255), not count. there's no max registrations per peer anywhere in Config or the rest of the codebase.
making it worse MAX TTL = 72 hours. so every registration just sits there for up to 3 days. disconnecting doesn't clean anything up either, entries only go away when the TTL fires.
protocols/rendezvous/src/server.rs
 └── Registrations::add()  ← no per-peer count check anywhere

protocols/rendezvous/src/lib.rs
 ├── MAX NAMESPACE = 255  ← length capped, count is not
 └── MAX TTL = 72h     ← entries persist a long time
fix would be adding something like max registrations per peer to Config and checking it at the top of add() before inserting anything.

PoC

tested on libp2p v0.56.1, built from source.
step 1 - start the rendezvous server (uses the example from the repo):
cargo run --manifest-path examples/rendezvous/Cargo.toml --bin rendezvous-example
step 2 - run the flood client (attached as rzv-flood.rs):
cargo run --manifest-path examples/rendezvous/Cargo.toml --bin rzv-flood
it connects as a single peer and registers 10,000 unique namespaces (flood-00000000 through flood-00009999), chaining each registration on the confirmed Registered event from the previous one.
server accepted every single one. not one rejection.
memory on the server side (via ps aux RSS column):
baseline:    ~18 MB
mid flood:   ~26 MB 
after 10k regs: ~28 MB
that's from one peer. scale to 100 sybil peers doing the same thing and you're looking at ~1GB. 1000 peers and the server is dead.
image
server RSS climbing during the flood
image
10,000 registrations confirmed, zero rejected

Impact

any node running libp2p-rendezvous server-side is affected. rendezvous servers are typically well-known, publicly reachable nodes taking one down disrupts peer discovery for all clients depending on it. any rust-libp2p based project that deploys a rendezvous point is at risk.
no special position on the network needed. no crypto work. just open a connection and send REGISTER in a loop.

Fix

Allocation of Resources Without Limits

Weakness Enumeration

CWE-770

Related Identifiers

CVE-2026-35405
GHSA-CQFX-GF56-8X59

Affected Products

Libp2P-Rendezvous