libp2p
libp2p: The Python implementation of the libp2p networking stack
Activity
- Latest release
- 2mo ago
- Total releases
- 21
- Cadence
- ~43 days
- Last 12 months
- 4
Reach
- Stars
- —
Details
- License
- MIT AND Apache-2.0
- First release
- Oct 23, 2018
| Version | Released | |
|---|---|---|
0.7.0
minor
1 CVE
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev | ||
0.6.0
minor
1 CVE
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev | ||
0.5.0
minor
1 CVE
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev | ||
0.4.0
minor
1 CVE
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev | ||
0.3.0
minor
1 CVE
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev | ||
0.2.9
patch
1 CVE
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev | ||
0.2.8
patch
1 CVE
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev | ||
0.2.7
patch
1 CVE
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev | ||
0.2.6
patch
1 CVE
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev | ||
0.2.5
patch
1 CVE
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev | ||
0.2.4
patch
1 CVE
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev | ||
0.2.3
patch
1 CVE
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev | ||
0.2.2
patch
2 CVEs
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev
CVE-2025-29606
PYSEC-2026-1536
GHSA-x8c6-gj59-6rx8
Jul 07, 2026
py-libp2p is vulnerable to DoS attacks through use of large RSA keys
4.3
/ 10
Medium
Network
Low
Low
None
Unchanged
None
None
Low
py-libp2p before 0.2.3 allows a peer to cause a denial of service (resource consumption) via a large RSA key. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
Fixed in
0.2.3
References
Updated Jul 07, 2026 · Source: OSV.dev | ||
0.2.1
patch
2 CVEs
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev
CVE-2025-29606
PYSEC-2026-1536
GHSA-x8c6-gj59-6rx8
Jul 07, 2026
py-libp2p is vulnerable to DoS attacks through use of large RSA keys
4.3
/ 10
Medium
Network
Low
Low
None
Unchanged
None
None
Low
py-libp2p before 0.2.3 allows a peer to cause a denial of service (resource consumption) via a large RSA key. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
Fixed in
0.2.3
References
Updated Jul 07, 2026 · Source: OSV.dev | ||
0.2.0
minor
2 CVEs
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev
CVE-2025-29606
PYSEC-2026-1536
GHSA-x8c6-gj59-6rx8
Jul 07, 2026
py-libp2p is vulnerable to DoS attacks through use of large RSA keys
4.3
/ 10
Medium
Network
Low
Low
None
Unchanged
None
None
Low
py-libp2p before 0.2.3 allows a peer to cause a denial of service (resource consumption) via a large RSA key. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
Fixed in
0.2.3
References
Updated Jul 07, 2026 · Source: OSV.dev | ||
0.1.5
patch
2 CVEs
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev
CVE-2025-29606
PYSEC-2026-1536
GHSA-x8c6-gj59-6rx8
Jul 07, 2026
py-libp2p is vulnerable to DoS attacks through use of large RSA keys
4.3
/ 10
Medium
Network
Low
Low
None
Unchanged
None
None
Low
py-libp2p before 0.2.3 allows a peer to cause a denial of service (resource consumption) via a large RSA key. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
Fixed in
0.2.3
References
Updated Jul 07, 2026 · Source: OSV.dev | ||
0.1.4
patch
2 CVEs
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev
CVE-2025-29606
PYSEC-2026-1536
GHSA-x8c6-gj59-6rx8
Jul 07, 2026
py-libp2p is vulnerable to DoS attacks through use of large RSA keys
4.3
/ 10
Medium
Network
Low
Low
None
Unchanged
None
None
Low
py-libp2p before 0.2.3 allows a peer to cause a denial of service (resource consumption) via a large RSA key. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
Fixed in
0.2.3
References
Updated Jul 07, 2026 · Source: OSV.dev |
0.1.4
patch
Dependencies (33)
+ 25 more
Changelog
Compare changes
|
|
0.1.3
patch
2 CVEs
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev
CVE-2025-29606
PYSEC-2026-1536
GHSA-x8c6-gj59-6rx8
Jul 07, 2026
py-libp2p is vulnerable to DoS attacks through use of large RSA keys
4.3
/ 10
Medium
Network
Low
Low
None
Unchanged
None
None
Low
py-libp2p before 0.2.3 allows a peer to cause a denial of service (resource consumption) via a large RSA key. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
Fixed in
0.2.3
References
Updated Jul 07, 2026 · Source: OSV.dev | ||
0.1.2
patch
2 CVEs
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev
CVE-2025-29606
PYSEC-2026-1536
GHSA-x8c6-gj59-6rx8
Jul 07, 2026
py-libp2p is vulnerable to DoS attacks through use of large RSA keys
4.3
/ 10
Medium
Network
Low
Low
None
Unchanged
None
None
Low
py-libp2p before 0.2.3 allows a peer to cause a denial of service (resource consumption) via a large RSA key. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
Fixed in
0.2.3
References
Updated Jul 07, 2026 · Source: OSV.dev | ||
0.1.1
initial
2 CVEs
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev
CVE-2025-29606
PYSEC-2026-1536
GHSA-x8c6-gj59-6rx8
Jul 07, 2026
py-libp2p is vulnerable to DoS attacks through use of large RSA keys
4.3
/ 10
Medium
Network
Low
Low
None
Unchanged
None
None
Low
py-libp2p before 0.2.3 allows a peer to cause a denial of service (resource consumption) via a large RSA key. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
Fixed in
0.2.3
References
Updated Jul 07, 2026 · Source: OSV.dev | ||
0.1.0a0
pre
2 CVEs
CVE-2026-73568
PYSEC-2026-3681
GHSA-hmj8-5xmh-5573
Aug 19, 2026
libp2p: yamux connection DoS via oversized data frame
7.5
/ 10
High
Network
Low
None
None
Unchanged
None
None
High
SummaryThe 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 DetailsIn
The
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 PoCThe 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
Malicious frame (12 bytes, hex):
Output:
ImpactA single authenticated peer (one that has completed the noise handshake, which requires no credentials) can permanently freeze the yamux read loop for a given connection using 12 bytes of payload. All streams on that connection stop working. No exception is raised, no log entry is written, and no automatic recovery occurs. This applies to the default There is no confidentiality or integrity impact. The effect is limited to availability on the targeted yamux connection. Remediation1. Enforce the receive window on inbound DATA frames (primary fix)
Before calling
The same check should be applied to the SYN branch at lines 804 to 806. 2. Add a per-frame timeout in
Option 1 eliminates the amplification entirely. Option 2 bounds the worst-case stall duration for any future oversized-read path that might be introduced. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
0.2.3
0.2.4
0.2.5
+ 9 more Show less
0.2.6
0.2.7
0.2.8
0.2.9
0.3.0
0.4.0
0.5.0
0.6.0
0.7.0
References
Updated Aug 19, 2026 · Source: OSV.dev
CVE-2025-29606
PYSEC-2026-1536
GHSA-x8c6-gj59-6rx8
Jul 07, 2026
py-libp2p is vulnerable to DoS attacks through use of large RSA keys
4.3
/ 10
Medium
Network
Low
Low
None
Unchanged
None
None
Low
py-libp2p before 0.2.3 allows a peer to cause a denial of service (resource consumption) via a large RSA key. Affected versions
0.1.0a0
0.1.1
0.1.2
0.1.3
0.1.4
0.1.5
0.2.0
0.2.1
0.2.2
Fixed in
0.2.3
References
Updated Jul 07, 2026 · Source: OSV.dev |