ALPINE-CVE-2026-97034: Alpine/go 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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
alpine/goto a version that resolves this vulnerability.Fixed in 1.26.11-r0
Event History
Frequently Asked Questions
Who is exposed to this issue?
Build environments using GCC to compile a malicious Go package that uses cgo are exposed when the package supplies affected #cgo LDFLAGS. The risk is during linking, not necessarily when running the resulting program.
What does an attacker need to exploit it?
An attacker needs to cause a victim to build a malicious cgo package with GCC and link flags using -fopenmp, -fopenacc, or -fsanitize=. They also need an untrusted GCC spec file to be found through a relevant -L or sysroot path, or through the working directory in the specified cases.
Are default build configurations affected?
The described behavior requires specific #cgo LDFLAGS that trigger GCC's libgomp or libsanitizer spec inclusion. The provided data does not indicate that ordinary cgo builds without -fopenmp, -fopenacc, or -fsanitize= are affected.
What can be done if updating is not immediately possible?
Avoid building untrusted cgo packages that use the affected linker flags, and do not allow untrusted directories in -L, -isysroot, or -Wl,-syslibroot arguments. Ensure relevant search paths, including applicable working and package directories, do not contain specs or *.spec files.
How can I identify a potentially affected build?
Review #cgo LDFLAGS for -fopenmp, -fopenacc, or -fsanitize=, especially with -static or -static-lib* for sanitizer builds. Check directories referenced by -L, -isysroot, and -Wl,-syslibroot, plus applicable working and package directories, for GCC spec files named specs or ending in .spec.