CVE-2026-77384 in libp2p
Summary
by MITRE • 08/25/2026
libp2p is a JavaScript implementation of the libp2p networking stack. Prior to version 4.2.9, the reservation refresh path in reservation-store.ts reuses the same retimeableSignal but unconditionally registers another abort listener on every refresh. As a result, a remote peer can repeatedly send valid RESERVE requests for the same reservation, causing unbounded listener and closure growth in @libp2p/circuit-relay-v2 relay servers and leading to denial of service. This issue is fixed in version 4.2.9.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/25/2026
The vulnerability identified within libp2p versions prior to 4.2.9 represents a significant resource exhaustion flaw located specifically within the reservation refresh mechanism of the circuit-relay-v2 module. Libp2p serves as a modular peer-to-peer networking stack, and its relay functionality allows nodes to connect through intermediate peers when direct connections are not possible due to firewalls or network address translation barriers. The core technical defect resides in the implementation details of the reservation-store.ts file, where the logic for refreshing existing reservations fails to properly manage event listeners associated with AbortSignal objects. Specifically, while the code reuses a single reusable signal object intended to track cancellation states across multiple refresh cycles, it unconditionally appends a new abort listener to this shared signal every time a refresh operation is triggered. This architectural oversight means that each subsequent reservation refresh adds another layer of callback registration without removing or replacing the previous listeners attached to the same underlying event source.
From an operational perspective, this design flaw creates a linear accumulation of memory and processing overhead with every successful reservation refresh initiated by a remote peer. An attacker who can communicate with a relay server running a vulnerable version of libp2p can exploit this behavior by repeatedly sending valid RESERVE requests for the same reservation identifier. Because each request triggers a refresh cycle that adds yet another listener to the shared signal, the number of active closures grows unbounded over time. This leads directly to a denial of service condition characterized by excessive memory consumption and potential thread blocking or garbage collection pressure on the relay server. The impact is particularly severe for public-facing relay nodes which handle high volumes of connection requests, as sustained exploitation can render the node unresponsive or cause it to crash entirely due to resource limits being exceeded.
This vulnerability aligns with CWE-787 Out-of-bounds Write in a broader sense of memory management failure and more accurately maps to CWE-400 Uncontrolled Resource Consumption, which describes scenarios where an application consumes resources without adequate bounds checking or cleanup mechanisms. In the context of the MITRE ATT&CK framework for network-based attacks, this behavior is consistent with T1498 Network Denial of Service, specifically subcategory 2 Direct Network Flood if viewed as a resource exhaustion vector rather than pure bandwidth saturation. The attack does not require complex payload injection or authentication bypass; it relies solely on the protocol's legitimate request mechanisms being abused through frequency and repetition against a flawed state management implementation.
The recommended mitigation is to upgrade libp2p to version 4.2.9 or later, where this issue has been resolved by correcting the listener registration logic in the reservation-store module. Developers integrating libp2p into their applications should ensure that dependency updates are applied promptly and monitored for security advisories related to resource management. For environments where immediate patching is not feasible, implementing rate limiting on RESERVE requests at a reverse proxy or load balancer layer can help mitigate the risk by preventing any single peer from triggering an excessive number of refresh cycles in a short timeframe. Additionally, monitoring relay node memory usage and listener counts can serve as an early detection mechanism for potential exploitation attempts before critical resource thresholds are breached.