UBUNTU-CVE-2026-97038: Medium severity ubuntu/golang-1.10 vulnerability
Building a malicious package containing ".syso" files or cgo linker inputs could inject arbitrary linker flags or execute arbitrary code at link time. Linker input files—including ".syso" files, direct object or library inputs in "#cgo LDFLAGS", and libraries in "-L" directories—were passed to the external linker without validating their format or checking for embedded linker options. Across platforms, this allowed executing GNU ld implicit linker scripts disguised as libraries or ".syso" files (or loaded via "-l:<filename>" or "-l" containing path separators), injecting unallowlisted linker flags via PE/COFF ".drectve" sections on Windows or Mach-O "LCLINKEROPTION" load commands on Darwin, or invoking LTO plugins via GCC or LLVM LTO intermediate representation sections in ELF, PE/COFF, or Mach-O objects. The go command now verifies that ".syso" files, direct linker inputs, and libraries in "-L" directories are valid binary objects or archives that do not contain unallowlisted ".drectve" directives, "LCLINKEROPTION" load commands, or LTO IR sections, and disallows "-l:<filename>" and ":", "=", or path separators in "-l" flags.
Affected Software
Event History
Frequently Asked Questions
Who is exposed to this issue?
Build environments using the listed Ubuntu golang packages are exposed when they link attacker-controlled or otherwise untrusted .syso files, cgo linker inputs, or libraries supplied through -L directories. The impact occurs during the build/link step rather than from merely running an already-built application.
What does an attacker need to exploit it?
An attacker needs a way to cause a Go build to consume malicious linker input, such as a .syso file, a direct object or library referenced by #cgo LDFLAGS, or a library found in a supplied -L directory. Malicious inputs can use linker scripts, embedded linker-option directives, or LTO intermediate-representation sections to introduce flags or execute code at link time.
Are all platforms affected in the same way?
GNU ld implicit linker scripts can affect builds across platforms. PE/COFF .drectve directives are relevant on Windows, Mach-O LC_LINKER_OPTION commands on Darwin, and LTO intermediate-representation sections can be present in ELF, PE/COFF, or Mach-O objects.
What can be done before updating the Go package?
Do not build untrusted source trees or accept untrusted .syso files, cgo linker inputs, or libraries from -L directories. Review #cgo LDFLAGS and reject -l:<filename> forms, -l values containing colons, equals signs, or path separators, and binary inputs containing linker-option or LTO content.
How does the corrected behavior prevent exploitation?
The go command validates .syso files, direct linker inputs, and libraries in -L directories as binary objects or archives, and rejects unallowlisted .drectve directives, LC_LINKER_OPTION commands, and LTO IR sections. It also disallows -l:<filename> and -l flags containing :, =, or path separators.