Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
2 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
The rendezvous server stores pagination cookies without bounds. An unauthenticated peer can repeatedly issue DISCOVER requests and force unbounded memory growth. Details Pagination state is stored in: On Message::Discover: There is no upper bound or eviction policy, so repeated DISCOVER requests grow this map indefinitely. PoC A reproduction test and minimal harness will be provided in a private fork in a follow-up comment. Impact Remote state amplification leading to memory exhaustion. Properties: - etwork reachable - no authentication required - low attack complexity - protocol-compliant traffic Impacts rendezvous nodes exposed to untrusted peers. --- Possible Fixes 1. Global cap + eviction Bound cookie storage (MAXCOOKIESTRACKED) with FIFO/expiry aware eviction. Tradeoff: attacker can churn cookies and evict legitimate pagination state. 2. Stateless cookies Encode pagination state in authenticated cookies instead of storing server-side state. Tradeoff: more complex…
Recommended action: Upgrade to 0.17.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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. no auth required. 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: - registrationsforpeer (BiMap) - registrations (HashMap) - nextexpiry (FuturesUnordered a new heap-allocated BoxFuture per registration) namespace strings are only validated for length (MAXNAMESPACE = 255), not count. there's no…
Recommended action: Upgrade to 0.17.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.