A synchronization issue in the Go standard library net/http package affects HTTP/1 servers using MaxBytesReader or MaxBytesHandler. When the MaxBytesReader limit is exceeded, the "Connection: close" header is set automatically without proper synchronization, which can race with other headers set explicitly by the server handler. This race condition can cause the server to crash due to a runtime panic if the handler reads the request body concurrently with writing the response header. Fixed versions 1.26.11 and 1.27.4 address this issue.
CVE-2026-94439 is a high-severity vulnerability in the Go standard library net/http package involving inconsistent handling of HTTP/1 CONNECT requests. When a server handler sends a 2xx response to such a request but does not hijack the connection, it incorrectly continues to process the connection as HTTP rather than as a tunnel. This behavior can lead to HTTP request smuggling, where intermediaries and the server have differing interpretations of the connection data.
CVE-2026-78660 is a high-severity vulnerability in the Go standard library net/http package involving inconsistent interpretation of HTTP requests, leading to HTTP response smuggling. The issue arises because the HTTP/2 implementation in net/http is lax about malformed framing-related headers, which can be forwarded to HTTP/1 clients when acting as a reverse proxy. If the HTTP/1 client also does not strictly validate these headers, response smuggling can occur.
CVE-2026-78659 is a high-severity vulnerability in the Go standard library net/http package. It involves asymmetric resource consumption through the handling of "Trailer" headers in HTTP/2 servers. A malicious client can send a "Trailer" header declaring many fields, causing excessive memory allocation by the server. This bypasses existing limits on header size and count, leading to potential denial-of-service conditions. The issue does not affect HTTP/1 servers due to different header handling and lack of multiplexing. No known exploits are reported in the wild. Affected versions include multiple pre-1.26.9 and pre-1.27.2 releases, as well as versions before 0.60.0. No patch or official fix information is provided in the input data.
CVE-2026-56866 is a high-severity vulnerability in the Go standard library net/http package involving inconsistent interpretation of HTTP/1 CONNECT requests with non-empty bodies. When http.Transport sends such a CONNECT request, it writes the body without framing after headers. If the server rejects the CONNECT request with a non-2xx keep-alive response, the connection is returned to the idle pool while the server may interpret trailing body bytes as a new pipelined HTTP/1.1 request. This desynchronization can cause response poisoning in reverse proxies that share the Transport, leading to cross-user response contamination.
CVE-2026-78669 is a high-severity vulnerability in the Go standard library net/http package. It involves asymmetric resource consumption (amplification) via HTTP/2 where a malicious peer can cause excessive CPU usage by opening many streams and sending numerous small SETTINGS frames with SETTINGS_INITIAL_WINDOW_SIZE values. This can impact both clients and servers using the affected versions of the net/http package.
CVE-2026-78663 is a critical vulnerability in the Go standard library net/http package affecting HTTP/2 servers. It allows a malicious client to bypass the configured connection-level flow control limit by causing the server to refund flow control credits twice for the same data. This occurs when a client resets a stream and the request handler subsequently reads buffered data, resulting in double refunding of connection-level flow control. Although total buffered data remains limited by concurrent stream limits and stream-level flow control, this flaw can lead to denial of service or resource exhaustion.
HTTP/2 servers could end up crashing due to inadvertently modifying its HPACK encoder concurrently. This happens because the server modifies the HPACK encoder from two goroutines without synchronization: one uses the encoder to encode a HEADERS frame as part of a response sent to a client and the other modifies the encoder's table size when handling a SETTINGS frame containing SETTINGS_HEADER_TABLE_SIZE that a client sends. A malicious client can repeatedly send a request while changing the header table size to crash the server.
When parsing a Range header containing a large number of small ranges, FileServer(FS), ServeContent, and ServeFile(FS) can consume an excessive amount of CPU.
CVE-2026-56853 is a high-severity vulnerability in the Go standard library net/http package. It occurs when a server supports unencrypted HTTP/2 and reads initial bytes from new connections to detect the HTTP/2 client preface. During this process, the ReadHeaderTimeout setting is not applied as expected, leading to allocation of resources without proper limits or throttling. This can cause denial of service by exhausting server resources.
The ToASCII and ToUnicode functions incorrectly accept Punycode-encoded labels that decode to an ASCII-only label. For example, ToUnicode("xn--example-.com") incorrectly returns the name "example.com" rather than an error. This behavior can lead to privilege escalation in programs using the idna package. For example, a program which performs privilege checks on the ASCII hostname may reject "example.com" but permit "xn--example-.com". If that program subsequently converts the ASCII hostname to Unicode, it will inadvertently permits access to the Unicode name "example.com".
When processing HTTP/2 SETTINGS frames, transport will enter an infinite loop of writing CONTINUATION frames if it receives a SETTINGS_MAX_FRAME_SIZE with a value of 0.
CVE-2025-58186 is a medium severity vulnerability in the Go standard library net/http package. It involves uncontrolled resource consumption due to the lack of a limit on the number of cookies parsed, despite an overall HTTP header size limit of 1MB. An attacker can exploit this by sending many small cookies, causing the server to allocate excessive memory and degrade availability.
An attacker may cause an HTTP/2 endpoint to read arbitrary amounts of header data by sending an excessive number of CONTINUATION frames. Maintaining HPACK state requires parsing and processing all HEADERS and CONTINUATION frames on a connection. When a request's headers exceed MaxHeaderBytes, no memory is allocated to store the excess headers, but they are still parsed. This permits an attacker to cause an HTTP/2 endpoint to read arbitrary amounts of header data, all associated with a request which is going to be rejected. These headers can include Huffman-encoded data which is significantly more expensive for the receiver to decode than for an attacker to send. The fix sets a limit on the amount of excess header frames we will process before closing a connection.