CVE-2026-46679: libp2p Gossipsub Heap Exhaustion DoS (7.5 HIGH)

Technical summary

The vulnerability stems from three cooperating omissions in @libp2p/gossipsub's input validation and resource management logic. An unauthenticated peer can send specially crafted gossip protocol messages that trigger unbounded heap allocation on the receiving node. The root causes align with improper input validation (CWE-20), unrestricted resource consumption (CWE-400), and resource management defects (CWE-401). The network-based attack vector requires no special privileges or user interaction, making it trivial to exploit against default deployments. Memory exhaustion forces the Node.js process into an out-of-memory condition, causing immediate service disruption.

Business impact

Organizations relying on libp2p gossipsub for peer-to-peer consensus, messaging, or distributed networking face immediate availability risk. A single malicious or compromised peer can take down entire nodes in the network, fragmenting connectivity and halting time-sensitive operations. For blockchain projects, DeFi protocols, or decentralized applications using gossipsub, this translates to network instability, failed transactions, and potential financial loss. Recovery requires manual intervention to restart affected nodes, introducing operational overhead and extending outage windows.

Affected systems

Any application using @libp2p/gossipsub versions prior to 15.0.23 is vulnerable. This includes Go, Rust, and JavaScript implementations of IPFS, Filecoin, Polkadot, and other peer-to-peer systems that depend on libp2p for gossip-based message propagation. The default configuration is exploitable; no special setup is required to trigger the flaw. Systems running patched versions (15.0.23 and later) are protected.

Exploitability

This vulnerability is trivial to exploit. An attacker requires only network connectivity to a target gossipsub node—no credentials, authentication tokens, or user interaction are necessary. The attack is passive from the target's perspective (no social engineering) and can be automated. Crafting exploit payloads is straightforward given the nature of the flaw; proof-of-concept code would be simple to develop. The lack of any access control or rate-limiting barriers makes this a high-confidence, low-friction attack path.

Remediation

Upgrade @libp2p/gossipsub to version 15.0.23 or later immediately. This patch version addresses all three underlying omissions and restores proper input validation and resource limits. For projects unable to upgrade immediately, network-level mitigations (traffic filtering, peer allowlisting, or rate-limiting at the protocol layer) provide temporary risk reduction but are not substitutes for the patch. After patching, restart affected nodes to clear any residual heap pressure.

Patch guidance

Apply the patch by upgrading @libp2p/gossipsub to version 15.0.23 or a later release in your package manager (npm, yarn, etc.). Verify the upgrade in your lock file and run full integration tests against your peer-to-peer network before deployment. Roll out patched nodes incrementally if operating a large distributed system to avoid cascading effects. Monitor node health metrics (memory usage, uptime) during and after the rollout to confirm the patch took effect and no regressions occurred.

Detection guidance

Look for sudden or sustained heap memory growth on gossipsub nodes accompanied by out-of-memory errors or process crashes. Monitor peer connection logs for repeated messages from a single or small cluster of peers immediately before crashes. Network-based detection is difficult without protocol-level introspection; focus on behavioral signals such as abnormal resource consumption spikes correlated with specific peer activity. Logging enhancements in libp2p itself (post-patch) may help attribute crashes to this specific attack pattern.

Why prioritize this

This vulnerability merits immediate attention due to its trivial exploitability, high availability impact, and the ease with which a lone attacker can disable production infrastructure. The CVSS 7.5 HIGH score reflects the severity of denial-of-service in peer-to-peer networks where availability is often critical. Organizations operating gossipsub-dependent services should prioritize patching within days, not weeks, to close this gap before opportunistic or targeted exploitation occurs.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) is driven by the attack vector (network-based), low complexity, no privilege or user interaction required, and high availability impact. The lack of confidentiality and integrity loss prevents a maximum score, but the ease and certainty of denial-of-service justifies the HIGH rating. In the context of peer-to-peer and blockchain applications, where uptime and network health are business-critical, the real-world impact may exceed the base CVSS score; organizations should consider raised internal risk scores for mission-critical deployments.

Frequently asked questions