AZL-113459: CVE-2026-97034 affecting package golang 1.27.4-1
When using GCC, building a malicious package that uses cgo could cause arbitrary command execution at link time via untrusted GCC spec files ("specs" or ".spec"). When linking with "-fopenmp", "-fopenacc", or "-fsanitize=" in "#cgo LDFLAGS", GCC's built-in link spec evaluates "%:include(libgomp.spec)" or "%:include(libsanitizer.spec)" and searches for spec files in "-L" and sysroot directories (including subdirectories and multilib sibling directories such as "../lib64"), as well as the working directory when "-fopenmp" or "-fopenacc" is used or when "-fsanitize=" is combined with "-static" or "-static-lib". The go command now rejects "-L", "-isysroot", and "-Wl,-syslibroot" directories (and the working and package directories when applicable) that contain GCC spec files, and disallows "@" and "-" prefixes in "-fsanitize=" compiler flag values.
Affected Software
Event History
Frequently Asked Questions
What conditions are required for exploitation?
A malicious package must use cgo and supply relevant #cgo LDFLAGS. Exploitation relies on GCC processing an untrusted specs or *.spec file during linking, triggered by -fopenmp, -fopenacc, or -fsanitize= flags under the described search conditions.
Which build locations can make an untrusted GCC spec file reachable?
GCC can search -L and sysroot directories, including their subdirectories and multilib sibling directories such as ../lib64. The working directory is also searched for -fopenmp or -fopenacc, and when -fsanitize= is used with -static or -static-lib*.
What mitigations are implemented in the updated go command?
The go command rejects -L, -isysroot, and -Wl,-syslibroot directories containing GCC spec files, as well as applicable working and package directories. It also disallows @ and - prefixes in -fsanitize= compiler flag values.