UBUNTU-CVE-2026-97034: Medium severity ubuntu/golang-1.10 vulnerability
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
Who is exposed to exploitation?
Build environments that compile a malicious package using cgo with attacker-controlled #cgo LDFLAGS are exposed. Exploitation requires GCC linking with -fopenmp, -fopenacc, or -fsanitize= under the specified conditions.
Which locations can supply a malicious GCC spec file?
GCC can search -L and sysroot directories, including their subdirectories and multilib sibling directories such as ../lib64. The working directory can also be searched for -fopenmp or -fopenacc, and for -fsanitize= combined with -static or -static-lib*.
What protections does the updated Go command provide?
The Go command rejects -L, -isysroot, and -Wl,-syslibroot directories containing GCC spec files. Where applicable, it also rejects spec files in the working and package directories and disallows @ and - prefixes in -fsanitize= compiler flag values.