CVE-2024-45336

When parsing a multipart form in Go, limits on the total form size were not applied to memory consumed while reading a single form line. This allows an attacker to send a malicious request causing excessive memory consumption.

A vulnerability in the LookPath function causes that when the PATH environment variable contains paths to executable files (rather than just directories), passing certain strings ("", ".", "..") can unexpectedly return binaries listed in PATH.

The vulnerability in the os.OpenFile implementation in Go causes different behavior on Unix and Windows systems when the target path is a dangling symlink. On Unix, the O_EXCL flag prevents following symlinks, while on Windows the function may follow the symlink to a nonexistent location.

A vulnerability in Go's HTTP/2 implementation allows a malicious client to rapidly create and reset requests, causing excessive server resource consumption. Although the number of concurrent streams is limited by MaxConcurrentStreams, resetting requests enables the attacker to continuously send new requests.

The filepath package in Go does not recognize paths with a \??\ prefix as special. On Windows, a path starting with \??\ is equivalent to a path starting with \\?\ and can be used to access arbitrary system locations.

The Go HTTP/1 client does not fully validate the contents of the Host header. A maliciously crafted Host header can inject additional headers or entire requests. The fix prevents sending requests with invalid Request.Host or Request.URL.Host values.

A vulnerability in the Go standard parser causes a panic when processing source code with deeply nested literals. The issue stems from stack exhaustion during recursive parsing.

A vulnerability in the os package of the Go standard library allows improper access to the parent directory of an os.Root by opening a filename ending in "../". For example, Root.Open("../") opens the parent directory, bypassing access restrictions.

A malicious GOPROXY was previously capable of forging up to two sumdb tiles that allow for a requested module to bypass the GOSUMDB check and persist attacker-controlled module content to a local Go module cache. This attack allows for a malicious GOPROXY to serve malicious module content that cannot be detected by evaluating the transparency log. All tiles are now correctly verified against their parents. In order to determine if you have been affected: rm -r go.sum go.work.sum vendor/ && go mod tidy

A malicious GOSUMDB was capable of serving arbitrary module content not contained within the transparency log. This attack allows for a coordinating GOPROXY and GOSUMDB to serve a client malicious module content that cannot be detected by evaluating the transparency log. In order to determine if you have been affected: rm -r go.sum go.work.sum vendor/ && go mod tidy