https://feed.craftedsignal.io/tags/libp2p/Trending threats, MITRE ATT&CK coverage, and detection metadata — refreshed continuously.Hugoenhello@craftedsignal.iohello@craftedsignal.ioSat, 04 Apr 2026 06:33:46 +0000https://feed.craftedsignal.io/briefs/2026-04-libp2p-rendezvous-dos/Sat, 04 Apr 2026 06:33:46 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-04-libp2p-rendezvous-dos/A vulnerable libp2p-rendezvous server can be crashed via a denial-of-service attack where an unauthenticated peer registers unlimited namespaces, leading to memory exhaustion.The libp2p-rendezvous server prior to version 0.17.1 is susceptible to a denial-of-service (DoS) attack. An attacker can exploit the lack of limitations on namespace registrations per peer. By repeatedly registering unique namespaces, the server allocates memory without restriction, leading to an out-of-memory (OOM) crash. This vulnerability requires no authentication, allowing any peer on the network to initiate the attack. The issue stems from the Registrations::add() function in protocols/rendezvous/src/server.rs, which does not enforce a maximum number of registrations per peer. The MAX_TTL of 72 hours exacerbates the problem, as registrations persist for up to three days even if the peer disconnects.

Attack Chain

1. Attacker connects to a publicly accessible libp2p-rendezvous server.
2. Attacker sends a REGISTER request to the server for a unique namespace.
3. The server’s Registrations::add() function processes the request and adds the namespace to its internal data structures (registrations_for_peer, registrations, next_expiry).
4. The attacker repeats steps 2 and 3 in a loop, registering thousands of unique namespaces.
5. The server continues to allocate memory for each namespace registration.
6. Due to the MAX_TTL of 72 hours, previously registered namespaces are not removed from memory.
7. The server’s memory consumption increases steadily with each registered namespace.
8. The server process eventually exhausts available memory (OOM) and crashes, disrupting peer discovery services for legitimate clients.

Impact

Successful exploitation of this vulnerability leads to a denial-of-service condition, making the libp2p-rendezvous server unavailable. Any rust-libp2p based project that deploys a rendezvous point is at risk. Since rendezvous servers are often well-known and publicly reachable, their downtime disrupts peer discovery for all clients relying on them. The impact scales with the number of attacking peers, requiring only a single connection and REGISTER requests to achieve the DoS. The affected package is rust/libp2p-rendezvous versions prior to 0.17.1.

Recommendation

• Upgrade to rust/libp2p-rendezvous version 0.17.1 or later to patch CVE-2026-35405.
• Monitor resource utilization (CPU, memory) of libp2p-rendezvous server processes to detect anomalous spikes indicative of a DoS attack.
• Implement rate limiting on namespace registration requests from individual peers in the application layer.

]]>highadvisorylibp2prendezvousdenial-of-servicehttps://feed.craftedsignal.io/briefs/2026-03-libp2p-gossipsub-dos/Mon, 30 Mar 2026 13:04:03 +0000hello@craftedsignal.iohttps://feed.craftedsignal.io/briefs/2026-03-libp2p-gossipsub-dos/A remote, unauthenticated attacker can crash applications using libp2p-gossipsub versions prior to 0.49.4 by sending a crafted PRUNE control message with a near-maximum backoff value, causing an arithmetic overflow during heartbeat processing.The Rust libp2p Gossipsub implementation, a peer-to-peer networking library, is susceptible to a remote denial-of-service (DoS) vulnerability. This flaw resides in the handling of backoff expiry during heartbeat processing. By sending a specially crafted PRUNE control message containing an attacker-controlled, near-maximum backoff value, a remote, unauthenticated peer can trigger an integer overflow. This overflow occurs when the implementation performs unchecked addition of the backoff_time and a slack value. This vulnerability affects applications using libp2p-gossipsub versions prior to 0.49.4 and is distinct from CVE-2026-33040, which addressed overflow during backoff insertion. This report highlights a distinct secondary overflow path in heartbeat expiry handling that remained exploitable even after the initial insertion-side hardening. The vulnerability was reported by the Security team of the Ethereum Foundation.

Attack Chain

1. An attacker establishes a standard libp2p session with a target node using TCP + Noise for encryption.
2. The attacker negotiates a stream multiplexer protocol such as mplex or yamux.
3. The attacker opens a Gossipsub stream with the target node to initiate communication.
4. The attacker sends an RPC (Remote Procedure Call) containing a ControlPrune message.
5. The ControlPrune message includes a crafted backoff value set near the maximum representable value for an i64 integer (e.g., 9223372036854674580). The attacker chooses this value relative to the victim’s uptime.
6. The target node parses the backoff value from the protobuf message and processes it using Behaviour::handle_prune().
7. The backoff value is stored after a checked addition to ensure it’s valid, however the near-maximum value is still retained.
8. On the next heartbeat, the node attempts to calculate the expiry time by adding a slack value to the stored backoff_time using unchecked addition, which results in an integer overflow, causing a panic and crashing the application.

Impact

This vulnerability results in a remote, unauthenticated denial of service. Any application exposing an affected libp2p-gossipsub listener can be crashed by a network-reachable peer. The crash occurs during heartbeat processing, not immediately upon receiving the PRUNE message. The attack can be repeated by reconnecting to the target and replaying the crafted PRUNE message. This could lead to service disruptions and potential data loss if the application does not handle crashes gracefully. The number of potential victims is significant, encompassing any application utilizing vulnerable versions of the libp2p-gossipsub library.

Recommendation

• Upgrade the libp2p-gossipsub dependency to version 0.49.4 or later to patch the unchecked arithmetic operation that causes the overflow.
• Deploy the Sigma rule “Detect libp2p Gossipsub PRUNE with Large Backoff” to identify potential exploitation attempts by monitoring network traffic for unusually large backoff values in PRUNE messages.
• Enable network connection logging to capture details of libp2p sessions and identify potential malicious peers attempting to exploit this vulnerability (logsource: network_connection).

]]>highadvisorylibp2pgossipsubdenial-of-serviceinteger overflowrust