{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "libp2p-rendezvous"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.17.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-35405"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-770"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-04T06:33:46Z",
    "nvd_published_at": "2026-04-07T15:17:43Z",
    "severity": "HIGH"
  },
  "details": "### Summary\n\nThe`libp2p-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.\n\nNo auth is required; therefore, any peer on the network can do this.\n\n\n\n### Details\n\nthe bug is in `Registrations::add()` inside `protocols/rendezvous/src/server.rs`.\n\nthe store uses a BiMap keyed on `(PeerId, Namespace)`  so yes, a peer can\u0027t register the *same* namespace twice. but there\u0027s nothing stopping it from registering 10,000 *different* namespaces. each unique one gets its own entry in:\n\n- `registrations_for_peer` (BiMap)\n- `registrations` (HashMap)\n- `next_expiry` (FuturesUnordered  a new heap-allocated BoxFuture per registration)\n\nnamespace strings are only validated for length (`MAX_NAMESPACE = 255`), not count. there\u0027s no `max_registrations_per_peer` anywhere in `Config` or the rest of the codebase.\n\nmaking it worse  `MAX_TTL = 72 hours`. so every registration just sits there for up to 3 days. disconnecting doesn\u0027t clean anything up either, entries only go away when the TTL fires.\n\n```\nprotocols/rendezvous/src/server.rs\n  \u2514\u2500\u2500 Registrations::add()   \u2190 no per-peer count check anywhere\n\nprotocols/rendezvous/src/lib.rs\n  \u251c\u2500\u2500 MAX_NAMESPACE = 255    \u2190 length capped, count is not\n  \u2514\u2500\u2500 MAX_TTL = 72h          \u2190 entries persist a long time\n```\n\nfix would be adding something like `max_registrations_per_peer` to `Config` and checking it at the top of `add()` before inserting anything.\n\n\n\n### PoC\n\ntested on `libp2p v0.56.1`, built from source.\n\n**step 1** -  start the rendezvous server (uses the example from the repo):\n```bash\ncargo run --manifest-path examples/rendezvous/Cargo.toml --bin rendezvous-example\n```\n\n**step 2** -  run the flood client (attached as `rzv-flood.rs`):\n```bash\ncargo run --manifest-path examples/rendezvous/Cargo.toml --bin rzv-flood\n```\n\nit 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.\n\nserver accepted every single one. not one rejection.\n\nmemory on the server side (via `ps aux` RSS column):\n\n```\nbaseline:       ~18 MB\nmid flood:      ~26 MB  \nafter 10k regs: ~28 MB\n```\n\nthat\u0027s from one peer. scale to 100 sybil peers doing the same thing and you\u0027re looking at ~1GB. 1000 peers and the server is dead.\n\n\u003cimg width=\"1032\" height=\"124\" alt=\"image\" src=\"https://github.com/user-attachments/assets/f778f179-2aa1-4485-940c-25e218733fa8\" /\u003e\n\n*server RSS climbing during the flood*\n\n\u003cimg width=\"553\" height=\"760\" alt=\"image\" src=\"https://github.com/user-attachments/assets/691b0f52-dda0-443f-a3c2-98c8c6336f2f\" /\u003e\n\n*10,000 registrations confirmed, zero rejected*\n\n\n\n### Impact\n\nany 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.\n\nno special position on the network needed. no crypto work. just open a connection and send REGISTER in a loop.",
  "id": "GHSA-cqfx-gf56-8x59",
  "modified": "2026-04-07T19:59:36Z",
  "published": "2026-04-04T06:33:46Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/libp2p/rust-libp2p/security/advisories/GHSA-cqfx-gf56-8x59"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-35405"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/libp2p/rust-libp2p"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "libp2p-rendezvous: Unlimited namespace registrations per peer enables OOM DoS on rendezvous servers"
}