https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 06:12:32 +0000 https://cve.radiocsirt.org/vuln/bdu:2026-05579 bdu:2026-05579 https://cve.radiocsirt.org/vuln/bdu:2026-05579 https://cve.radiocsirt.org/vuln/euvd-2026-290290 EUVD-2026-290290 https://cve.radiocsirt.org/vuln/euvd-2026-290290 https://cve.radiocsirt.org/vuln/fkie_cve-2026-35405 <p>libp2p-rust is the official rust language Implementation of the libp2p networking stack. Prior to 0.17.1, libp2p-rendezvous server has no limit on how many namespaces a single peer can register. A malicious peer can just keep registering unique namespaces in a loop and the server happily accepts every single one allocating memory for each registration with no pushback. Keep doing this long enough (or with multiple sybil peers) and the server process gets OOM killed. This vulnerability is fixed in 0.17.1.</p> <p>libp2p-rust is the official rust language Implementation of the libp2p networking stack. Prior to 0.17.1, libp2p-rendezvous server has no limit on how many namespaces a single peer can register. A malicious peer can just keep registering unique namespaces in a loop and the server happily accepts every single one allocating memory for each registration with no pushback. Keep doing this long enough (or with multiple sybil peers) and the server process gets OOM killed. This vulnerability is fixed in 0.17.1.</p> https://cve.radiocsirt.org/vuln/fkie_cve-2026-35405 https://cve.radiocsirt.org/vuln/ghsa-cqfx-gf56-8x59 <p><strong>Affected:</strong> crates.io: libp2p-rendezvous</p> <p>### Summary found that `libp2p-rendezvous` server has no limit on how many namespaces a single peer can register. a malicious peer can just keep registering unique namespaces in a loop and the server happily accepts every single one allocating memory for each registration with no pushback. keep doing this long enough (or with multiple sybil peers) and the server process gets OOM killed.</p> <p>no auth required. any peer on the network can do this.</p> <p>### Details</p> <p>the bug is in `Registrations::add()` inside `protocols/rendezvous/src/server.rs`.</p> <p>the store uses a BiMap keyed on `(PeerId, Namespace)` so yes, a peer can&#39;t register the *same* namespace twice. but there&#39;s nothing stopping it from registering 10,000 *different* namespaces. each unique one gets its own entry in:</p> <p>- `registrations_for_peer` (BiMap) - `registrations` (HashMap) - `next_expiry` (FuturesUnordered a new heap-allocated BoxFuture per registration)</p> <p>namespace strings are only validated for length (`MAX_NAMESPACE = 255`), not count. there&#39;s no `max_registrations_per_peer` anywhere in `Config` or the rest of the codebase.</p> <p>making it worse `MAX_TTL = 72 hours`. so every registration just sits there for up to 3 days. disconnecting doesn&#39;t clean anything up either, entries only go away when the TTL fires.</p> <p>``` protocols/rendezvous/src/server.rs └── Registrations::add() ← no per-peer count check anywhere</p> <p>protocols/rendezvous/src/lib.rs ├── MAX_NAMESPACE = 255 ← length capped, count is not └── MAX_TTL = 7…</p> <p><strong>Affected:</strong> crates.io: libp2p-rendezvous</p> <p>### Summary found that `libp2p-rendezvous` server has no limit on how many namespaces a single peer can register. a malicious peer can just keep registering unique namespaces in a loop and the server happily accepts every single one allocating memory for each registration with no pushback. keep doing this long enough (or with multiple sybil peers) and the server process gets OOM killed.</p> <p>no auth required. any peer on the network can do this.</p> <p>### Details</p> <p>the bug is in `Registrations::add()` inside `protocols/rendezvous/src/server.rs`.</p> <p>the store uses a BiMap keyed on `(PeerId, Namespace)` so yes, a peer can&#39;t register the *same* namespace twice. but there&#39;s nothing stopping it from registering 10,000 *different* namespaces. each unique one gets its own entry in:</p> <p>- `registrations_for_peer` (BiMap) - `registrations` (HashMap) - `next_expiry` (FuturesUnordered a new heap-allocated BoxFuture per registration)</p> <p>namespace strings are only validated for length (`MAX_NAMESPACE = 255`), not count. there&#39;s no `max_registrations_per_peer` anywhere in `Config` or the rest of the codebase.</p> <p>making it worse `MAX_TTL = 72 hours`. so every registration just sits there for up to 3 days. disconnecting doesn&#39;t clean anything up either, entries only go away when the TTL fires.</p> <p>``` protocols/rendezvous/src/server.rs └── Registrations::add() ← no per-peer count check anywhere</p> <p>protocols/rendezvous/src/lib.rs ├── MAX_NAMESPACE = 255 ← length capped, count is not └── MAX_TTL = 7…</p> https://cve.radiocsirt.org/vuln/ghsa-cqfx-gf56-8x59