<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Js-Libp2p — CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/js-libp2p/</link><description>Trending threats, MITRE ATT&amp;CK coverage, and detection metadata. Fed continuously.</description><generator>Hugo</generator><language>en</language><managingEditor>hello@craftedsignal.io</managingEditor><webMaster>hello@craftedsignal.io</webMaster><lastBuildDate>Thu, 21 May 2026 21:40:43 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/js-libp2p/feed.xml" rel="self" type="application/rss+xml"/><item><title>js-libp2p Gossipsub Memory Exhaustion via Subscription Flood</title><link>https://feed.craftedsignal.io/briefs/2026-05-js-libp2p-dos/</link><pubDate>Thu, 21 May 2026 21:40:43 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-05-js-libp2p-dos/</guid><description>A memory exhaustion vulnerability exists in `@libp2p/gossipsub` due to unbounded subscription handling, allowing a single attacker to exhaust a Node.js heap by flooding unique topic subscriptions, leading to denial-of-service.</description><content:encoded><![CDATA[<p>A memory exhaustion vulnerability has been identified in <code>@libp2p/gossipsub</code>, a component of the js-libp2p library. The vulnerability stems from three design flaws: the lack of a decode-level cap on subscription entries per RPC (<code>defaultDecodeRpcLimits.maxSubscriptions = Infinity</code>), unbounded growth in the <code>handleReceivedSubscription</code> function, and the failure to remove empty Sets from <code>this.topics</code> after a peer disconnect in the <code>removePeer</code> function. This allows an unauthenticated peer to exhaust the Node.js heap of a gossipsub node with default options by sending a flood of unique topic subscriptions. A single 4MB frame can carry 349,525 unique topic SUBSCRIBE entries, causing approximately 89MB of heap growth, leading to a crash after around 17 frames, demonstrating a significant amplification factor. This affects any gossipsub node with default options.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>Attacker dials a victim node and opens a gossipsub stream.</li>
<li>The attacker&rsquo;s initial score is 0, which is greater than the default <code>gossipThreshold</code> of -10, allowing subscriptions to be processed immediately without score checks.</li>
<li>The attacker constructs a malicious RPC message containing 349,525 SUBSCRIBE entries, each with a unique 6-character topic string. The total encoded size of this RPC is approximately 4MB.</li>
<li>The victim&rsquo;s <code>handleReceivedRpc</code> processes the RPC and iterates through each subscription entry, calling <code>handleReceivedSubscription</code> for each unique topic.</li>
<li><code>handleReceivedSubscription</code> adds each new topic to the <code>this.topics</code> map without any limits or per-peer count restrictions, leading to uncontrolled memory allocation.</li>
<li>The victim&rsquo;s <code>this.topics</code> map grows by 349,525 entries, consuming approximately 89MB of heap space and blocking the event loop for approximately 224ms.</li>
<li>The attacker reconnects and repeats the process, sending additional RPCs with unique topic subscriptions. No score decay or penalties are applied.</li>
<li>After approximately 17 rounds, the Node.js process exhausts its 1.5GB heap limit, resulting in an Out-Of-Memory (OOM) crash, causing a denial-of-service.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>Successful exploitation of this vulnerability leads to a denial-of-service condition, as the target Node.js process crashes due to memory exhaustion. The attack requires only approximately 68MB of total attacker bandwidth, achievable in approximately 5 seconds at 100Mbps. The vulnerability affects any gossipsub node running with default options, making it a widespread risk. The memory leak in <code>removePeer</code> also contributes to long-term performance degradation as <code>this.topics</code> accumulates entries.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Apply patches to <code>@libp2p/gossipsub</code> to limit the number of subscriptions accepted per RPC and implement per-peer topic count limits.</li>
<li>Implement a mechanism to remove empty Sets from <code>this.topics</code> in the <code>removePeer</code> function to prevent memory leaks, mitigating defect 3.</li>
<li>Deploy the Sigma rule &ldquo;Detect High Topic Count in Gossipsub Subscriptions&rdquo; to identify and potentially block malicious subscription floods.</li>
<li>Monitor Node.js process memory usage and restart gossipsub nodes exceeding a defined memory threshold to mitigate the impact of memory exhaustion.</li>
<li>Review and adjust the default <code>gossipThreshold</code> to require higher scores for subscription processing, potentially mitigating step 2 of the attack chain.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">threat</category><category>dos</category><category>memory-exhaustion</category><category>libp2p</category></item></channel></rss>