Go vulnerabilities

The Go HTTP client drops sensitive headers (e.g., Authorization) after a cross-domain redirect, but may re-send them on a subsequent same-domain redirect, posing a potential data leak risk.

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.

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 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 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 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

Handshake messages, such as KeyUpdate, are always considered as state-advancing, regardless of whether a handshake has been completed or not. As a result, a malicious client can keep sending KeyUpdate messages to force the server to keep performing key derivation operations indefinitely.

Previously, resolving relative paths containing parent directory ('..') segments performed string conversions and buffer rewrites on each step, resulting in quadratic time complexity and high memory allocation overhead. Now, path resolution operates on a byte buffer using index-based backtracking for '..' segments, eliminating the quadratic time complexity and significantly reducing memory allocations.

Previously, DecodeElement would reset the depth counter causing it to never fire; this could lead to stack exhaustion.

Previously, pathological inputs could close an unescaped '/' early, allowing for attack-controlled data to inject arbitrary content, potentially leading to XSS.

On Unix systems, opening a file in an os.Root improperly follows symlinks to locations outside of the Root when the final path component is a symbolic link and the path ends in /. For example, 'root.Open("symlink/")' will open "symlink" even when it points outside the root.

A vulnerability in Go's (*x509.Certificate).VerifyHostname function causes quadratic verification cost scaling with a large DNS SAN list. An attacker can exploit this to cause a denial of service by providing a certificate with many SAN entries.

A vulnerability in the cgo DNS resolver in Go (when using LookupCNAME) causes a double-free of C memory and a crash when handling a very long CNAME response.

When verifying a certificate chain with excluded DNS constraints, these constraints are not correctly applied to wildcard DNS SANs with different case. This affects only otherwise trusted chains issued by a root CA.

In Go, context was not properly tracked across template branches for JS template literals, leading to incorrect escaping. Template actions within JS template literals also did not track brace depth, causing improper escaping. These issues could lead to XSS vulnerabilities.

The tar.Reader function in Go can allocate an unbounded amount of memory when reading a maliciously crafted archive containing a large number of sparse regions encoded in the 'old GNU sparse map' format.

On Linux, if the target of Root.Chmod is replaced with a symlink during the chmod operation, Chmod can operate on the symlink target even if it lies outside the root. The fchmodat syscall silently ignores the AT_SYMLINK_NOFOLLOW flag. Root.Chmod checks its target before acting and returns an error if the target is a symlink outside the root, so impact is limited to cases where the target is replaced between check and operation.

The url.Parse function in Go insufficiently validates the host/authority component and accepts some invalid URLs.

A discrepancy between how Go and C/C++ comments were parsed allowed for code smuggling into the resulting cgo binary.