js-libp2p EUVD-2026-65154

The target must be running a js-libp2p node configured as a circuit-relay-v2 relay server - nodes acting solely as clients or ordinary peers are not affected. The CVSS vector (PR:N, UI:N, AV:N, AC:L) confirms exploitation requires no authentication, no user interaction, and no special network position beyond TCP/QUIC reachability to the relay server. The RESERVE messages themselves must be valid (well-formed protocol messages from a recognized peer), meaning the attacker must participate in the libp2p network as a legitimate peer identity; however, generating a peer identity is trivial and unauthenticated in practice. What limits exploitation: only relay server deployments are vulnerable, not all js-libp2p nodes; the attack is a resource exhaustion DoS without remote code execution or data exfiltration; and the growth rate is bounded by network throughput to the target.

The CVSS 3.1 vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) accurately captures the threat profile: network-reachable with no authentication, low complexity, and high availability impact. The attack is trivially automatable - an adversary only needs to repeatedly send valid protocol-conforming RESERVE messages, requiring no exploit of a memory safety bug or race condition. No EPSS data was provided in the input, and this CVE does not appear in the CISA KEV catalog, suggesting no confirmed active exploitation at time of analysis. Despite the absence of KEV listing, the operational risk for relay operators is genuine: even a small, focused DoS campaign against a relay node serving a decentralized application's network could disrupt connectivity for many dependent peers. The impact is bounded to availability (no confidentiality or integrity loss), and the vulnerability only affects nodes configured to operate as circuit-relay-v2 relay servers, which limits the exposed population. The fix is a one-line conditional guard confirmed in the upstream commit, with a dedicated regression test, giving high confidence in the patch.

An attacker connects to a js-libp2p relay server as a valid peer and repeatedly sends RESERVE protocol messages for the same relay slot in a tight loop. Each message is valid and processed normally by the server, which refreshes the reservation and attaches a new abort listener to the reused signal without removing the previous one. After thousands of iterations, the relay server's Node.js process memory grows unboundedly until the event loop degrades or the process is killed by the OS, denying relay service to all legitimate peers. No public proof-of-concept code has been identified, but the attack requires only standard libp2p protocol messages.