AZL-113645: CVE-2026-97040 affecting package tensorflow 2.16.1-11
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 issue occurs during linking, where metadata embedded in that file can reach the external linker.
What does an attacker need to exploit it?
An attacker needs to get a crafted .syso file included in a package being built. The file can use a Go object header and embed untrusted cgo metadata directives such as cgo_ldflag or cgo_dynamic_linker.
Are pure-Go builds affected?
Yes. An unrecognized .syso format could force external linking even in pure-Go builds, creating a path for the malicious metadata to be processed.
What can be done before an updated toolchain is available?
Do not build packages containing untrusted .syso files, and review .syso inputs from dependencies or source archives. In particular, treat .syso files that present as Go objects or contain cgo linker-related metadata as unsafe.