GO-2026-6853: Arbitrary code execution via crafted .syso files and cgo linker input files in cmd/go
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
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/toolchainto a version that resolves this vulnerability.Fixed in 1.26.11 - Upgrade
Upgrade
go/toolchainto a version that resolves this vulnerability.Fixed in 1.27.4
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Build environments that compile untrusted or third-party Go packages are exposed when those packages can supply .syso files or cgo linker inputs. The risk occurs during linking, so CI systems and developer workstations that build such packages are relevant targets.
What does an attacker need to control to exploit it?
An attacker needs to cause a target to build a malicious package containing crafted .syso files, direct object or library inputs in #cgo LDFLAGS, or libraries found through -L directories. The crafted input can exploit linker-script handling, embedded linker options, or LTO intermediate-representation sections.
What can be done before an updated toolchain is available?
Do not build untrusted packages that include .syso files or cgo linker inputs. In particular, review or reject direct linker inputs, libraries supplied through -L directories, and -l flags using a colon, equals sign, or path separators.
Which kinds of embedded linker behavior are relevant on different platforms?
GNU ld implicit linker scripts can be disguised as libraries or .syso files across platforms. Windows PE/COFF .drectve sections and Darwin Mach-O LC_LINKER_OPTION commands can inject linker options, while LTO IR sections in ELF, PE/COFF, or Mach-O objects can invoke GCC or LLVM LTO plugins.