AZL-113414: CVE-2026-97040 affecting package gcc 13.2.0-7
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 exposed to this issue?
Build environments that compile a package containing an attacker-crafted .syso file are exposed. The crafted file can carry cgo metadata directives that reach the external linker without validation.
What does an attacker need to exploit it?
An attacker needs to cause a package with a crafted .syso file to be built. The .syso file must begin with a Go object header so it is parsed as a Go compiler object rather than a recognized host object format.
Are pure-Go builds affected?
Unrecognized .syso formats could force external linking even in pure-Go builds. The issue is triggered by processing .syso entries from a package archive.
What changes address the issue?
The linker rejects .syso files that are not recognized host object formats. The build and archive tools also preserve the .syso suffix when truncating long archive member names.