Most recent entries from all

EUVD-2026-278318

fkie_cve-2026-34219

libp2p-rust is the official rust language Implementation of the libp2p networking stack. Prior to version 0.49.4, the Rust libp2p Gossipsub implementation contains a remotely reachable panic in backoff expiry handling. After a peer sends a crafted PRUNE control message with an attacker-controlled, near-maximum backoff value, the value is accepted and stored as an Instant near the representable upper bound. On a later heartbeat, the implementation performs unchecked Instant + Duration arithmetic (backoff_time + slack), which can overflow and panic with: overflow when adding duration to instant. This issue is reachable from any Gossipsub peer over normal TCP + Noise + mplex/yamux connectivity and requires no further authentication beyond becoming a protocol peer. This issue has been patched in version 0.49.4.

GHSA-xqmp-fxgv-xvq5 — libp2p-gossipsub: Remote crash via unchecked Instant overflow in heartbeat backoff expiry handling

Affected: crates.io: libp2p-gossipsub

## Description ### Summary The Rust libp2p Gossipsub implementation contains a remotely reachable panic in `backoff` expiry handling. After a peer sends a crafted `PRUNE` control message with an attacker-controlled, near-maximum `backoff` value, the value is accepted and stored as an `Instant` near the representable upper bound. On a later heartbeat, the implementation performs unchecked `Instant + Duration` arithmetic (`backoff_time + slack`), which can overflow and panic with: `overflow when adding duration to instant` This issue is reachable from any Gossipsub peer over normal `TCP + Noise + mplex/yamux` connectivity and requires no further authentication beyond becoming a protocol peer. ### Attack Scenario An attacker that can establish a libp2p Gossipsub session with a target node can crash the target by sending crafted `PRUNE` control data: 1. Establish a standard libp2p session (`TCP + Noise`) and negotiate a stream multiplexer (`mplex`/`yamux`). 2. Open a Gossipsub stream and send an RPC containing `ControlPrune` with a very large `backoff` (chosen near boundary conditions, e.g. `~ i64::MAX - victim_uptime_seconds`; example observed: `9223372036854674580` for ~28h uptime). 3. The value is parsed from protobuf and passed through `Behaviour::handle_prune()` into mesh/backoff update logic. 4. Initial storage path uses checked addition (`Instant::now().checked_add(...)`), so the malicious near-max value is retained. 5. On the next heartbeat (typically within ~43–74s),…