libp2p floodsub EUVD-2026-81688

Exploitation requires that the target node runs @libp2p/floodsub (js-libp2p < 11.0.26) with the /floodsub/1.0.0 pubsub protocol enabled and accepting inbound connections from untrusted peers - the normal open peer-to-peer deployment mode. No authentication, credentials, or user interaction are needed (PR:N/UI:N), and because the subscription path bypasses message signature validation and the message-only processing queue, signature/peer-authentication defenses do not limit it. The primary limiting factor is that floodsub must actually be in use: it is a legacy pubsub protocol largely superseded by gossipsub, so nodes configured only with gossipsub or without pubsub are not affected. Persistent memory exhaustion additionally requires the attacker to send many unique-topic SUBSCRIBE entries; empty entries cause only transient CPU exhaustion without growing this.topics.

This is a network-reachable, unauthenticated denial-of-service flaw (CVSS 3.1 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) - availability-only impact, no confidentiality or integrity exposure. The vendor CVSS vector is internally consistent with the description: a remote peer speaking the /floodsub/1.0.0 protocol needs no credentials and no user interaction, and the subscription-processing path explicitly bypasses signature validation and the message queue, so attack complexity is genuinely low. No EPSS score, KEV entry, or public POC was provided in the input, so this is best characterized as no public exploit identified at time of analysis rather than active exploitation. The signals do not conflict: a moderately-severe (7.5) but purely-availability issue in a peer-to-peer library, with a fix already shipped (11.0.26) and a detailed public GitHub Security Advisory plus PR diff, is a legitimate patch-soon item for anyone running floodsub - but it is not a drop-everything emergency absent evidence of in-the-wild abuse. The main real-world risk driver is that floodsub peers accept connections from arbitrary untrusted peers by design, so the 'unauthenticated remote' precondition is effectively always met wherever the component is enabled.

A malicious peer connects to a target node over the /floodsub/1.0.0 protocol and sends a single bounded-size protobuf RPC frame that decodes into millions of empty subscription entries, which processRpc/processRpcSubOpt iterate synchronously and block the Node.js event loop, causing sustained CPU exhaustion. Alternatively the attacker sends hundreds of thousands of unique-topic SUBSCRIBE entries, permanently allocating PeerSet objects in this.topics that are never freed after peer removal, driving memory growth to out-of-memory termination. No public POC is referenced, but the GitHub advisory and fix PR (#3568) describe the mechanism in enough detail to reproduce.