Miggo at BlackHat 2026!
Easily map the attack path and prioritize which CVEs are a threat to your organization
Miggo AIGenerate vendor-ready rules for the observed attack patterns, plus reasoning and safe deployment guidance
| Package Name | Ecosystem | Vulnerable Versions | First Patched Version |
|---|---|---|---|
| libp2p-rendezvous | rust | < 0.17.1 | 0.17.1 |
Miggo AIRoot Cause Analysis: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.
server RSS climbing during the flood
10,000 registrations confirmed, zero rejected
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.
Discovered by:
Organization: Centre of Excellence in Complex & Nonlinear Dynamical Systems (CoE-CNDS Lab), Veermata Jijabai Technological Institute (VJTI), Mumbai, India
We have not disclosed this to any other vendor or made it public. We are reporting directly to the rust-libp2p security team through this advisory.