https://cve.radiocsirt.org Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 13:28:41 +0000 https://cve.radiocsirt.org/vuln/cve-2026-73568 <p><strong>Affected:</strong> libp2p py-libp2p</p> <p>py-libp2p is the Python implementation of the libp2p networking stack. In 0.7.0 and earlier, the yamux handle_incoming() method in libp2p/stream_muxer/yamux/yamux.py reads an attacker-controlled 32-bit DATA frame length with read_exactly() before validating it against MAX_WINDOW_SIZE or checking whether stream_id exists. A peer that completes the standard Noise handshake can send a 12-byte frame declaring a 0xFFFFFFFF body and then withhold the body, causing the sequential yamux read loop used by the default new_host() configuration to block and preventing every stream on that connection from making progress. No fixed version is available as of this review.</p> <p><strong>Affected:</strong> libp2p py-libp2p</p> <p>py-libp2p is the Python implementation of the libp2p networking stack. In 0.7.0 and earlier, the yamux handle_incoming() method in libp2p/stream_muxer/yamux/yamux.py reads an attacker-controlled 32-bit DATA frame length with read_exactly() before validating it against MAX_WINDOW_SIZE or checking whether stream_id exists. A peer that completes the standard Noise handshake can send a 12-byte frame declaring a 0xFFFFFFFF body and then withhold the body, causing the sequential yamux read loop used by the default new_host() configuration to block and preventing every stream on that connection from making progress. No fixed version is available as of this review.</p> https://cve.radiocsirt.org/vuln/cve-2026-73568 https://cve.radiocsirt.org/vuln/ghsa-hmj8-5xmh-5573 <p><strong>Affected:</strong> PyPI: libp2p</p> <p>### Summary The yamux stream multiplexer in py-libp2p does not validate incoming DATA frame lengths against the receive window before reading the frame body. Any peer that completes a standard libp2p handshake can send a single 12-byte frame claiming a 4 GB body, causing the victim&#39;s yamux read loop to block indefinitely. This affects the default `new_host()` configuration and requires no special setup on either side.</p> <p>### Details In `libp2p/stream_muxer/yamux/yamux.py` (lines 915 to 926), the `handle_incoming()` method dispatches on frame type. When a DATA frame arrives, it reads the body unconditionally:</p> <p>```python elif typ == TYPE_DATA: try: data = ( await read_exactly(self.secured_conn, length) if length &gt; 0 else b&#34;&#34; ) ```</p> <p>The `length` field is taken directly from the wire-decoded frame header, a 32-bit unsigned integer with a maximum value of 4,294,967,295. There is no check that `length` fits within the stream&#39;s receive window (`DEFAULT_WINDOW_SIZE = 256 * 1024` bytes). The body read also happens before the code checks whether the referenced `stream_id` even exists in `self.streams` (that check is at line 954), so any stream ID triggers the issue.</p> <p>`handle_incoming()` itself is a single sequential loop with no timeout around the body read. Once `read_exactly` suspends waiting for data that never comes, the loop cannot process any subsequent frames. Every stream on that yamux connection stops working, and no excep…</p> <p><strong>Affected:</strong> PyPI: libp2p</p> <p>### Summary The yamux stream multiplexer in py-libp2p does not validate incoming DATA frame lengths against the receive window before reading the frame body. Any peer that completes a standard libp2p handshake can send a single 12-byte frame claiming a 4 GB body, causing the victim&#39;s yamux read loop to block indefinitely. This affects the default `new_host()` configuration and requires no special setup on either side.</p> <p>### Details In `libp2p/stream_muxer/yamux/yamux.py` (lines 915 to 926), the `handle_incoming()` method dispatches on frame type. When a DATA frame arrives, it reads the body unconditionally:</p> <p>```python elif typ == TYPE_DATA: try: data = ( await read_exactly(self.secured_conn, length) if length &gt; 0 else b&#34;&#34; ) ```</p> <p>The `length` field is taken directly from the wire-decoded frame header, a 32-bit unsigned integer with a maximum value of 4,294,967,295. There is no check that `length` fits within the stream&#39;s receive window (`DEFAULT_WINDOW_SIZE = 256 * 1024` bytes). The body read also happens before the code checks whether the referenced `stream_id` even exists in `self.streams` (that check is at line 954), so any stream ID triggers the issue.</p> <p>`handle_incoming()` itself is a single sequential loop with no timeout around the body read. Once `read_exactly` suspends waiting for data that never comes, the loop cannot process any subsequent frames. Every stream on that yamux connection stops working, and no excep…</p> https://cve.radiocsirt.org/vuln/ghsa-hmj8-5xmh-5573