{"description":"Trending threats, MITRE ATT\u0026CK coverage, and detection metadata. Fed continuously.","feed_url":"https://feed.craftedsignal.io/products/py-libp2p--0.6.0/feed.json","home_page_url":"https://feed.craftedsignal.io/","items":[{"_cs_actors":[],"_cs_cpes":[],"_cs_cves":[],"_cs_exploited":false,"_cs_has_poc":false,"_cs_poc_references":[],"_cs_products":["py-libp2p (\u003c= 0.6.0)"],"_cs_severities":["medium"],"_cs_tags":["denial-of-service","vulnerability","network","python","libp2p"],"_cs_type":"advisory","_cs_vendors":["libp2p"],"content_html":"\u003cp\u003eA high-severity denial-of-service vulnerability, tracked as GHSA-hmj8-5xmh-5573, has been identified in the \u003ccode\u003epy-libp2p\u003c/code\u003e library, specifically affecting versions up to 0.6.0. The vulnerability resides in the \u003ccode\u003eyamux\u003c/code\u003e 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 \u003ccode\u003eyamux\u003c/code\u003e 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 \u003ccode\u003eyamux\u003c/code\u003e read loop (\u003ccode\u003ehandle_incoming()\u003c/code\u003e) 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 \u003ccode\u003enew_host()\u003c/code\u003e configuration, making a broad range of \u003ccode\u003epy-libp2p\u003c/code\u003e deployments vulnerable.\u003c/p\u003e\n\u003ch2 id=\"attack-chain\"\u003eAttack Chain\u003c/h2\u003e\n\u003col\u003e\n\u003cli\u003eAttacker and victim \u003ccode\u003epy-libp2p\u003c/code\u003e nodes establish a connection and complete a standard libp2p noise handshake for secure communication.\u003c/li\u003e\n\u003cli\u003eThe two nodes then negotiate and establish a \u003ccode\u003eyamux\u003c/code\u003e multiplexed connection over the secured channel.\u003c/li\u003e\n\u003cli\u003eThe attacker crafts a malicious 12-byte \u003ccode\u003eyamux\u003c/code\u003e frame with \u003ccode\u003eversion=0x00\u003c/code\u003e, \u003ccode\u003etype=DATA\u003c/code\u003e (or \u003ccode\u003eSYN\u003c/code\u003e), \u003ccode\u003eflags=0x0000\u003c/code\u003e, \u003ccode\u003estream_id=1\u003c/code\u003e, and a \u003ccode\u003elength\u003c/code\u003e field set to \u003ccode\u003e0xFFFFFFFF\u003c/code\u003e (4,294,967,295 bytes).\u003c/li\u003e\n\u003cli\u003eThe attacker writes this crafted 12-byte frame directly to the \u003ccode\u003esecured_conn\u003c/code\u003e (the encrypted channel).\u003c/li\u003e\n\u003cli\u003eThe victim's \u003ccode\u003eyamux\u003c/code\u003e multiplexer receives and decrypts the frame, then its \u003ccode\u003ehandle_incoming()\u003c/code\u003e method reads the 12-byte header.\u003c/li\u003e\n\u003cli\u003eThe \u003ccode\u003ehandle_incoming()\u003c/code\u003e method dispatches the frame based on its \u003ccode\u003eTYPE_DATA\u003c/code\u003e (or \u003ccode\u003eSYN\u003c/code\u003e) and subsequently calls \u003ccode\u003eread_exactly()\u003c/code\u003e with the malformed 4 GB length value.\u003c/li\u003e\n\u003cli\u003eBecause the attacker sends only the 12-byte header and no actual data matching the declared 4 GB length, \u003ccode\u003eread_exactly()\u003c/code\u003e enters an indefinite blocking state, waiting for data that will never arrive.\u003c/li\u003e\n\u003cli\u003eThis permanent block freezes the entire \u003ccode\u003ehandle_incoming()\u003c/code\u003e loop for that \u003ccode\u003eyamux\u003c/code\u003e connection, rendering all streams on it unusable, effectively achieving a denial of service.\u003c/li\u003e\n\u003c/ol\u003e\n\u003ch2 id=\"impact\"\u003eImpact\u003c/h2\u003e\n\u003cp\u003eThe vulnerability allows any authenticated peer to completely freeze a \u003ccode\u003eyamux\u003c/code\u003e 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 \u003ccode\u003enew_host()\u003c/code\u003e configuration for \u003ccode\u003epy-libp2p\u003c/code\u003e 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.\u003c/p\u003e\n\u003ch2 id=\"recommendation\"\u003eRecommendation\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003eUpdate \u003ccode\u003epy-libp2p\u003c/code\u003e 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.\u003c/li\u003e\n\u003cli\u003eImplement the proposed remediation of enforcing the receive window on inbound DATA frames before calling \u003ccode\u003eread_exactly()\u003c/code\u003e in \u003ccode\u003elibp2p/stream_muxer/yamux/yamux.py\u003c/code\u003e.\u003c/li\u003e\n\u003cli\u003eApply the proposed remediation of adding a per-frame timeout within the \u003ccode\u003ehandle_incoming()\u003c/code\u003e loop for \u003ccode\u003eyamux\u003c/code\u003e frames in \u003ccode\u003elibp2p/stream_muxer/yamux/yamux.py\u003c/code\u003e to prevent indefinite blocking.\u003c/li\u003e\n\u003c/ul\u003e\n","date_modified":"2026-07-24T22:38:05Z","date_published":"2026-07-24T22:38:05Z","id":"https://feed.craftedsignal.io/briefs/2026-07-py-libp2p-yamux-dos/","summary":"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.","title":"py-libp2p yamux Connection DoS via Oversized Data Frame","url":"https://feed.craftedsignal.io/briefs/2026-07-py-libp2p-yamux-dos/"}],"language":"en","title":"CraftedSignal Threat Feed - Py-Libp2p (\u003c= 0.6.0)","version":"https://jsonfeed.org/version/1.1"}