CVE-2026-25679

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.

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.

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.

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