<?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>Py-Libp2p (&lt;= 0.6.0) - CraftedSignal Threat Feed</title><link>https://feed.craftedsignal.io/products/py-libp2p--0.6.0/</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>Fri, 24 Jul 2026 22:38:05 +0000</lastBuildDate><atom:link href="https://feed.craftedsignal.io/products/py-libp2p--0.6.0/feed.xml" rel="self" type="application/rss+xml"/><item><title>py-libp2p yamux Connection DoS via Oversized Data Frame</title><link>https://feed.craftedsignal.io/briefs/2026-07-py-libp2p-yamux-dos/</link><pubDate>Fri, 24 Jul 2026 22:38:05 +0000</pubDate><author>hello@craftedsignal.io</author><guid isPermaLink="true">https://feed.craftedsignal.io/briefs/2026-07-py-libp2p-yamux-dos/</guid><description>A denial-of-service vulnerability in py-libp2p versions up to 0.6.0 allows an authenticated attacker to send a specially crafted 12-byte DATA or SYN frame with an oversized length field, causing the victim's yamux read loop to block indefinitely and freezing all streams on the affected connection.</description><content:encoded><![CDATA[<p>A high-severity denial-of-service vulnerability, tracked as GHSA-hmj8-5xmh-5573, has been identified in the <code>py-libp2p</code> library, specifically affecting versions up to 0.6.0. The vulnerability resides in the <code>yamux</code> stream multiplexer's handling of incoming DATA and SYN frames. After completing a standard libp2p noise handshake, an authenticated peer can send a malicious 12-byte <code>yamux</code> frame that specifies an oversized body length (e.g., 4 GB). Due to a lack of validation against the stream's receive window and the absence of a per-frame timeout, the victim's <code>yamux</code> read loop (<code>handle_incoming()</code>) attempts to read the specified enormous amount of data indefinitely. This permanently blocks the connection, making all streams on it unresponsive and causing a denial of service without raising exceptions or logging errors. This issue affects the default <code>new_host()</code> configuration, making a broad range of <code>py-libp2p</code> deployments vulnerable.</p>
<h2 id="attack-chain">Attack Chain</h2>
<ol>
<li>Attacker and victim <code>py-libp2p</code> nodes establish a connection and complete a standard libp2p noise handshake for secure communication.</li>
<li>The two nodes then negotiate and establish a <code>yamux</code> multiplexed connection over the secured channel.</li>
<li>The attacker crafts a malicious 12-byte <code>yamux</code> frame with <code>version=0x00</code>, <code>type=DATA</code> (or <code>SYN</code>), <code>flags=0x0000</code>, <code>stream_id=1</code>, and a <code>length</code> field set to <code>0xFFFFFFFF</code> (4,294,967,295 bytes).</li>
<li>The attacker writes this crafted 12-byte frame directly to the <code>secured_conn</code> (the encrypted channel).</li>
<li>The victim's <code>yamux</code> multiplexer receives and decrypts the frame, then its <code>handle_incoming()</code> method reads the 12-byte header.</li>
<li>The <code>handle_incoming()</code> method dispatches the frame based on its <code>TYPE_DATA</code> (or <code>SYN</code>) and subsequently calls <code>read_exactly()</code> with the malformed 4 GB length value.</li>
<li>Because the attacker sends only the 12-byte header and no actual data matching the declared 4 GB length, <code>read_exactly()</code> enters an indefinite blocking state, waiting for data that will never arrive.</li>
<li>This permanent block freezes the entire <code>handle_incoming()</code> loop for that <code>yamux</code> connection, rendering all streams on it unusable, effectively achieving a denial of service.</li>
</ol>
<h2 id="impact">Impact</h2>
<p>The vulnerability allows any authenticated peer to completely freeze a <code>yamux</code> connection using a mere 12-byte payload, resulting in a denial of service. All existing and future streams on the affected connection become unresponsive, preventing any further communication. This attack does not raise exceptions, generate error logs, or trigger any automatic recovery mechanisms, leading to a persistent DoS. Since the default <code>new_host()</code> configuration for <code>py-libp2p</code> is affected, a large number of deployments are vulnerable. An attacker could target multiple nodes, potentially freezing all their active connections if they exhaust the default connection limit (e.g., 10,000 connections using approximately 120 KB of total traffic). The impact is limited to availability, with no observed confidentiality or integrity compromise.</p>
<h2 id="recommendation">Recommendation</h2>
<ul>
<li>Update <code>py-libp2p</code> to version 0.6.1 or later to apply the official patch for GHSA-hmj8-5xmh-5573, which includes receive window validation and per-frame timeouts.</li>
<li>Implement the proposed remediation of enforcing the receive window on inbound DATA frames before calling <code>read_exactly()</code> in <code>libp2p/stream_muxer/yamux/yamux.py</code>.</li>
<li>Apply the proposed remediation of adding a per-frame timeout within the <code>handle_incoming()</code> loop for <code>yamux</code> frames in <code>libp2p/stream_muxer/yamux/yamux.py</code> to prevent indefinite blocking.</li>
</ul>
]]></content:encoded><category domain="severity">medium</category><category domain="type">advisory</category><category>denial-of-service</category><category>vulnerability</category><category>network</category><category>python</category><category>libp2p</category></item></channel></rss>