CVE-2026-27142

On Unix platforms, when listing the contents of a directory using File.ReadDir or File.Readdir, the returned FileInfo could reference a file outside of the Root in which the File was opened. The impact of this escape is limited to reading metadata provided by lstat from arbitrary locations on the filesystem without permitting reading or writing files outside the root.

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

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

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