Go net/http vulnerabilities

Parsing a multipart form can bypass memory limits and read an arbitrarily long line into memory when the remaining limit at the start of a part is less than 400 bytes.

When an HTTP server handler sends a 2xx response to an HTTP/1 CONNECT request and returns without hijacking the connection, the server improperly continues to read and serve requests from the connection. Since a 2xx response to CONNECT converts the connection into a tunnel, the server should not treat it as continuing to contain HTTP.

A malicious HTTP/2 peer can cause excessive CPU consumption in the client or server by opening a large number of streams and then sending many small SETTINGS frames containing SETTINGS_INITIAL_WINDOW_SIZE values.

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.

The HTTP/2 server can refund connection-level flow control twice for the same data: once when a client resets a stream, and again when a request handler reads the buffered data. A malicious client can exploit this to bypass the configured connection-level flow control limit (MaxReceiveBufferPerConnection).

Historically, the HTTP/2 implementation has been rather lax about malformed framing-related headers, as they cannot interfere with HTTP/2 framing. However, this makes it possible to forward responses containing such headers to an HTTP/1 client when acting as a reverse proxy. If the HTTP/1 client also does not behave strictly enough, this can result in response smuggling.

When "Trailer" headers are sent by a client, the HTTP server internally uses the header values to populate the Request.Trailer map passed to the server handler. Because Request.Trailer is a map, each entry incurs memory overhead. For HTTP/2 servers, a malicious client can exploit this by sending a "Trailer" header that declares a large number of fields, causing the server to allocate a disproportionate amount of memory while bypassing Server.MaxHeaderValueCount and Server.MaxHeaderBytes limits.

When http.Transport sends an HTTP/1 CONNECT request with a non-empty Request.Body, it writes the body directly to the connection without framing after the request headers. If the server rejects the CONNECT request with a non-2xx keep-alive response, Transport returns the connection to the idle pool. Because CONNECT requests do not have a request body, the server may interpret the trailing body bytes as a subsequent pipelined HTTP/1.1 request on the connection, leaving the pooled connection desynchronized and causing the next caller that reuses it to read the response to the injected request.

A vulnerability in the Go net/http library allows a malicious HTTP sender to use chunk extensions to force a receiver to read many more bytes from the network than are in the body. A malicious HTTP client can exploit this to cause a server to automatically read a large amount of data (up to about 1 GiB).

A vulnerability in the Go standard library (net/http) causes the HTTP client to not forward sensitive headers like Authorization or Cookie when following a redirect to a domain that is not a subdomain or exact match of the original domain. For example, a redirect from foo.com to www.foo.com will forward the Authorization header, but a redirect to a different domain will not.