AZL-113477: CVE-2026-97040 affecting package golang 1.27.4-1
Building a package containing a crafted ".syso" file could bypass cgo flag validation and inject arbitrary linker flags when linking. When loading ".syso" entries from a package archive, the linker only checked for recognized host object headers (ELF, Mach-O, PE, and XCOFF) before falling through to Go object parsing. A ".syso" file beginning with a "go object" header was parsed as a Go compiler object, allowing untrusted cgo metadata directives (such as "cgoldflag" or "cgodynamiclinker") embedded in the ".syso" file to be passed to the external linker without validation. Additionally, ".syso" filenames longer than 16 bytes lost their ".syso" extension when truncated in archive headers, and unrecognized ".syso" formats forced external linking in pure-Go builds. The linker now rejects ".syso" files that are not recognized host object formats, and "cmd/go" and "cmd/pack" preserve the ".syso" suffix when truncating long archive member names.
Affected Software
Event History
Frequently Asked Questions
Who is realistically exposed to this issue?
Build environments that compile or link packages containing untrusted .syso files are exposed. The attacker must be able to cause a crafted .syso file to be included in a package archive used by the build.
What does an attacker need to place in the crafted file?
The .syso file can begin with a Go object header and include untrusted cgo metadata directives such as cgo_ldflag or cgo_dynamic_linker. Those directives could then be passed to the external linker without cgo flag validation.
What changes prevent exploitation after remediation?
The linker rejects .syso files that are not recognized host object formats. cmd/go and cmd/pack also preserve the .syso suffix when truncating long archive member names.