Marten Seemann

10 exploits Active since Dec 2022
CVE-2023-39533 WRITEUP HIGH WRITEUP
go-libp2p < 0.27.8 - Resource Exhaustion via Large RSA Key Signature Verification
go-libp2p is the Go implementation of the libp2p Networking Stack. Prior to versions 0.27.8, 0.28.2, and 0.29.1 malicious peer can use large RSA keys to run a resource exhaustion attack & force a node to spend time doing signature verification of the large key. This vulnerability is present in the core/crypto module of go-libp2p and can occur during the Noise handshake and the libp2p x509 extension verification step. To prevent this attack, go-libp2p versions 0.27.8, 0.28.2, and 0.29.1 restrict RSA keys to <= 8192 bits. To protect one's application, it is necessary to update to these patch releases and to use the updated Go compiler in 1.20.7 or 1.19.12. There are no known workarounds for this issue.
CVSS 7.5
CVE-2023-39533 WRITEUP HIGH WRITEUP
go-libp2p < 0.27.8 - Resource Exhaustion via Large RSA Key Signature Verification
go-libp2p is the Go implementation of the libp2p Networking Stack. Prior to versions 0.27.8, 0.28.2, and 0.29.1 malicious peer can use large RSA keys to run a resource exhaustion attack & force a node to spend time doing signature verification of the large key. This vulnerability is present in the core/crypto module of go-libp2p and can occur during the Noise handshake and the libp2p x509 extension verification step. To prevent this attack, go-libp2p versions 0.27.8, 0.28.2, and 0.29.1 restrict RSA keys to <= 8192 bits. To protect one's application, it is necessary to update to these patch releases and to use the updated Go compiler in 1.20.7 or 1.19.12. There are no known workarounds for this issue.
CVSS 7.5
CVE-2022-23492 WRITEUP HIGH WRITEUP
libp2p < 0.18.0 - Resource Exhaustion via Connection and Stream Management
go-libp2p is the offical libp2p implementation in the Go programming language. Version `0.18.0` and older of go-libp2p are vulnerable to targeted resource exhaustion attacks. These attacks target libp2p’s connection, stream, peer, and memory management. An attacker can cause the allocation of large amounts of memory, ultimately leading to the process getting killed by the host’s operating system. While a connection manager tasked with keeping the number of connections within manageable limits has been part of go-libp2p, this component was designed to handle the regular churn of peers, not a targeted resource exhaustion attack. Users are advised to upgrade their version of go-libp2p to version `0.18.1` or newer. Users unable to upgrade may consult the denial of service (dos) mitigation page for more information on how to incorporate mitigation strategies, monitor your application, and respond to attacks.
CVSS 7.5
CVE-2023-39533 WRITEUP HIGH WRITEUP
go-libp2p < 0.27.8 - Resource Exhaustion via Large RSA Key Signature Verification
go-libp2p is the Go implementation of the libp2p Networking Stack. Prior to versions 0.27.8, 0.28.2, and 0.29.1 malicious peer can use large RSA keys to run a resource exhaustion attack & force a node to spend time doing signature verification of the large key. This vulnerability is present in the core/crypto module of go-libp2p and can occur during the Noise handshake and the libp2p x509 extension verification step. To prevent this attack, go-libp2p versions 0.27.8, 0.28.2, and 0.29.1 restrict RSA keys to <= 8192 bits. To protect one's application, it is necessary to update to these patch releases and to use the updated Go compiler in 1.20.7 or 1.19.12. There are no known workarounds for this issue.
CVSS 7.5
CVE-2023-40583 WRITEUP HIGH WRITEUP
libp2p < 0.27.4 - Uncontrolled Resource Consumption via Signed Peer Records
libp2p is a networking stack and library modularized out of The IPFS Project, and bundled separately for other tools to use. In go-libp2p, by using signed peer records a malicious actor can store an arbitrary amount of data in a remote node’s memory. This memory does not get garbage collected and so the victim can run out of memory and crash. If users of go-libp2p in production are not monitoring memory consumption over time, it could be a silent attack i.e. the attacker could bring down nodes over a period of time (how long depends on the node resources i.e. a go-libp2p node on a virtual server with 4 gb of memory takes about 90 sec to bring down; on a larger server, it might take a bit longer.) This issue was patched in version 0.27.4.
CVSS 7.5
CVE-2023-46239 WRITEUP HIGH WRITEUP
quic-go 0.37.0-0.37.3 - Denial of Service via Handshake Packet Number Space
quic-go is an implementation of the QUIC protocol in Go. Starting in version 0.37.0 and prior to version 0.37.3, by serializing an ACK frame after the CRYTPO that allows a node to complete the handshake, a remote node could trigger a nil pointer dereference (leading to a panic) when the node attempted to drop the Handshake packet number space. An attacker can bring down a quic-go node with very minimal effort. Completing the QUIC handshake only requires sending and receiving a few packets. Version 0.37.3 contains a patch. Versions before 0.37.0 are not affected.
CVSS 7.5
CVE-2023-49295 WRITEUP MEDIUM WRITEUP
quic-go < 0.37.7, 0.38.2, 0.39.4 - Uncontrolled Resource Consumption via PATH_CHALLENGE Frame Flood
quic-go is an implementation of the QUIC protocol (RFC 9000, RFC 9001, RFC 9002) in Go. An attacker can cause its peer to run out of memory sending a large number of PATH_CHALLENGE frames. The receiver is supposed to respond to each PATH_CHALLENGE frame with a PATH_RESPONSE frame. The attacker can prevent the receiver from sending out (the vast majority of) these PATH_RESPONSE frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate. This vulnerability has been patched in versions 0.37.7, 0.38.2 and 0.39.4.
CVSS 6.4
CVE-2024-22189 WRITEUP HIGH WRITEUP
quic-go < 0.42.0 - Denial of Service via NEW_CONNECTION_ID Frame Flood
quic-go is an implementation of the QUIC protocol in Go. Prior to version 0.42.0, an attacker can cause its peer to run out of memory sending a large number of `NEW_CONNECTION_ID` frames that retire old connection IDs. The receiver is supposed to respond to each retirement frame with a `RETIRE_CONNECTION_ID` frame. The attacker can prevent the receiver from sending out (the vast majority of) these `RETIRE_CONNECTION_ID` frames by collapsing the peers congestion window (by selectively acknowledging received packets) and by manipulating the peer's RTT estimate. Version 0.42.0 contains a patch for the issue. No known workarounds are available.
CVSS 7.5
CVE-2025-29785 WRITEUP HIGH WRITEUP
quic-go 0.50.0 - Denial of Service via Path Probe Packet Handling
quic-go is an implementation of the QUIC protocol in Go. The loss recovery logic for path probe packets that was added in the v0.50.0 release can be used to trigger a nil-pointer dereference by a malicious QUIC client. In order to do so, the attacker first sends valid QUIC packets from different remote addresses (thereby triggering the newly added path validation logic: the server sends path probe packets), and then sending ACKs for packets received from the server specifically crafted to trigger the nil-pointer dereference. v0.50.1 contains a patch that fixes the vulnerability. This release contains a test that generates random sequences of sent packets (both regular and path probe packets), that was used to verify that the patch actually covers all corner cases. No known workarounds are available.
CVSS 7.5
CVE-2025-64702 WRITEUP MEDIUM WRITEUP
quic-go < 0.57.0 - Memory Exhaustion via QPACK-Encoded HEADERS Frame
quic-go is an implementation of the QUIC protocol in Go. Versions 0.56.0 and below are vulnerable to excessive memory allocation through quic-go's HTTP/3 client and server implementations by sending a QPACK-encoded HEADERS frame that decodes into a large header field section (many unique header names and/or large values). The implementation builds an http.Header (used on the http.Request and http.Response, respectively), while only enforcing limits on the size of the (QPACK-compressed) HEADERS frame, but not on the decoded header, leading to memory exhaustion. This issue is fixed in version 0.57.0.
CVSS 5.3