Description

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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.5",
  "pubDate": "2026-08-13T18:18:19.547Z",
  "pubdate": "2026-08-13T18:18:19.547Z",
  "executiveSummary": "A denial of service vulnerability exists in py-libp2p version 0.7.0 and earlier within the yamux stream multiplexer implementation.\nThe vulnerability allows an authenticated remote attacker to completely stall stream progression on an affected connection by exploiting improper input validation and synchronous read behavior in the yamux handle_incoming() method.\nImpacted systems include any applications utilizing the py-libp2p networking stack configured with the default new_host() setup.\nRisk implications are high for availability, as a single malicious peer can permanently halt all multiplexed communication channels without requiring special privileges beyond completing the standard Noise handshake.\nNo fixed version is currently available as of this review, leaving deployments exposed to this resource exhaustion vector.",
  "technicalDetails": "The vulnerability resides in the yamux handle_incoming() method located at libp2p/stream_muxer/yamux/yamux.py.\nThe affected component fails to validate the attacker-controlled 32-bit DATA frame length against MAX_WINDOW_SIZE, and fails to check whether the specified stream_id exists before executing a read operation.\nSpecifically, the code invokes read_exactly() on the incoming stream prior to performing necessary bounds checks or state validations.\nThe exploitation flow begins after a peer successfully completes the standard Noise handshake, establishing an authenticated network session.\nThe malicious peer then transmits a crafted 12-byte frame that explicitly declares an excessively large body length of 0xFFFFFFFF.\nFollowing the transmission of this header, the attacker intentionally withholds the actual body payload.\nBecause the default new_host() configuration utilizes a sequential yamux read loop, the execution thread blocks indefinitely waiting for the remainder of the non-existent 4GB payload to arrive via read_exactly().\nThis blocking behavior halts the sequential read loop entirely, preventing every other stream multiplexed over that specific connection from making any further progress.\nAuthentication requirements are limited to completing the standard Noise handshake, meaning any network-exposed peer can trigger the condition.\nNo privilege escalation or post-exploitation execution is achieved; the impact is strictly localized to a persistent denial of service affecting stream processing and availability within the py-libp2p network stack."
}