Go toolchain

Exploited now

None of this vendor's CVEs are on CISA's known-exploited list.

Recent

• –UnscoredNov 11, 2026Go toolchain cmd/go Code / command injectionCVE-2026-97043Building a malicious package that uses cgo could bypass "#cgo LDFLAGS" validation and cause unexpected code execution at build time, or cause the go command to panic, via crafted quoting in "//go:cgo_ldflag" directives. When "cmd/cgo" generates "_cgo_gotypes.go", it quotes each "#cgo LDFLAGS" argument with strconv.Quote in a "//go:cgo_ldflag" directive, but "cmd/compile" and "cmd/go" parsed those directives by splitting on raw quote characters without handling backslash escapes or unquoting the
• –UnscoredNov 11, 2026Go toolchain cmd/cgo Code / command injectionCVE-2026-97042Building a malicious package that uses "//go:cgo_import_dynamic" or links against a crafted PE object on Windows could pass unsafe library arguments to the external linker. The compiler only checked the first character of the library name in "//go:cgo_import_dynamic" directives and skipped validation in cgo-generated files. In addition, on Windows, "cmd/cgo" and "cmd/link" did not validate imported DLL names extracted from PE object files before emitting "-l<name>" flags for the external linker,
• –UnscoredNov 11, 2026Go toolchain cmd/compile Code / command injectionCVE-2026-97041Building a malicious package containing "//go:cgo_*" compiler directives could inject arbitrary flags into the external linker invocation on ELF platforms. The compiler and linker did not reject commas in "//go:cgo_import_dynamic", "//go:cgo_export_dynamic", "//go:cgo_export_static", "//go:cgo_import_static", and "//go:cgo_dynamic_linker" directives, and the linker passed the dynamic linker path using "-Wl,--dynamic-linker,<path>". Furthermore, the two-argument form of "//go:cgo_import_dynamic"
• –UnscoredNov 11, 2026Go toolchain cmd/go Code / command injectionCVE-2026-97040Building 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 "cgo_ldflag" or "cgo_dynamic_linker") emb
• –UnscoredNov 11, 2026Go toolchain cmd/go Code / command injectionCVE-2026-97039Building a malicious package that uses "#cgo pkg-config:" directives could load untrusted pkg-config ".pc" files or inject unvalidated compiler and linker flags. The pkg-config flag allowlist previously permitted "--with-path=" and "--personality=", allowed "--define-variable=" values beginning with "=" or "$" (which can rewrite paths in system ".pc" files into sysroot-prefixed "-L=" or "-L$SYSROOT" linker search paths), and allowed package arguments ending in ".pc" or containing path separators
• –UnscoredNov 11, 2026Go toolchain cmd/go Code / command injectionCVE-2026-97038Building 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
• –UnscoredNov 11, 2026Go toolchain cmd/go Code / command injectionCVE-2026-97037Building a malicious package that uses cgo could cause arbitrary code execution at link time by passing linker script files to the host linker via "#cgo LDFLAGS". Split "-Wl," flags that consume a following argument (such as "-Wl,-rpath", "-Wl,--just-symbols", and "-Wl,-undefined") previously accepted a bare second argument without a "-Wl," prefix, which the compiler driver passes directly to the linker as a positional input file. Additionally, when using GNU ld.bfd, flags such as "-framework",
• –UnscoredNov 11, 2026Go toolchain cmd/go Code / command injectionCVE-2026-97036On Darwin, building a malicious package that uses cgo could cause arbitrary code execution when using the Apple linker due to passing "-l to_library <path>" in a "#cgo LDFLAGS" directive. The Apple linker recombines the separated arguments "-l" and "to_library" into "-lto_library", which loads an arbitrary LTO plugin dynamic library at link time. The go command now disallows "-l" followed by "to_library" in "#cgo LDFLAGS", rejects "-lazy_library", "-lazy_framework", "-load_hidden", "-library", a
• –UnscoredNov 11, 2026Go toolchain cmd/go Code / command injectionCVE-2026-97035When using Clang or GCC, building a malicious package that uses cgo could cause unexpected code execution at build time or write files to arbitrary directories via "-gen-*" or "-gnat*" flags in "#cgo" directives. The "-g*" wildcard in the compiler and linker flag allowlists previously matched Clang's two-argument "-gen-cdb-fragment-path <dir>" flag and GCC's two-argument "-gnatO <file>" flag, permitting compilation database fragments and sidecar output files to be written to arbitrary directorie
• –UnscoredNov 11, 2026Go toolchain cmd/go Code / command injectionCVE-2026-97034When using GCC, building a malicious package that uses cgo could cause arbitrary command execution at link time via untrusted GCC spec files ("specs" or "*.spec"). When linking with "-fopenmp", "-fopenacc", or "-fsanitize=" in "#cgo LDFLAGS", GCC's built-in link spec evaluates "%:include(libgomp.spec)" or "%:include(libsanitizer.spec)" and searches for spec files in "-L" and sysroot directories (including subdirectories and multilib sibling directories such as "../lib64"), as well as the working
• –UnscoredNov 11, 2026Go toolchain cmd/go Code / command injectionCVE-2026-97033Building a malicious package that uses cgo could cause arbitrary code execution at build time through several compiler and linker flags permitted in "#cgo" directives. Specifically, "--sysroot" in GCC and Clang relocates compiler subprograms, spec files, and CRT startup objects to an attacker-controlled directory; "-target" in Clang falls back to executing target helper tools from the current working directory when not found in PATH; "-isysroot" and "-Wl,-syslibroot" can pass a regular file on d
• 7.8HighOct 8, 2026Go toolchain cmd/goCVE-2026-94447Previously, a user operating inside of a malicious Go project that defines a bogus golang.org/toolchain go.sum entry and operates a malicious GOMODPROXY the user chooses to use can bypass the intended checksum. We now ensure that golang.org/toolchain always goes to the network for the canonical checksum.
• 7.8HighOct 8, 2026Go toolchain cmd/goCVE-2026-94444Previously, a user operating inside of a malicious Go project that defines a bogus golang.org/fips140 and operates a malicious GOMODPROXY the user chooses to connect to can serve an arbitrary module in its place. We now unpack the trusted ziphash for the bundled golang.org/fips140 module and construct its entry in the GOMODCACHE such that it can be verified by the toolchain.

See every Go toolchain entry on the dashboard.

Top products

• cmd/go11 CVEs in the last year
• cmd/compile1 CVE in the last year
• cmd/cgo1 CVE in the last year

Advisories

Official advisories from the last 90 days that name this vendor's CVEs.

• oss-security · Nov 10, 2026Go 1.27.4 and Go 1.26.11 are released with 12 security fixesCVE-2026-97033CVE-2026-97034CVE-2026-97035CVE-2026-97036CVE-2026-97037CVE-2026-97038
• oss-security · Nov 5, 2026Fwd: Go 1.27.4 and Go 1.26.11 pre-announcementCVE-2026-97033CVE-2026-97034CVE-2026-97035CVE-2026-97036CVE-2026-97037CVE-2026-97038