Vendor
45 published CVES affecting toolchain, from public sources (CVE.org, NVD, CISA KEV, FIRST EPSS, OSV).
Newest publication first · page 1 of 2
Building 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 t...
When 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 "%:...
When 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 previou...
On 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...
Building 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...
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—...
Building 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=" v...
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) befor...
Building 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_stati...
Building 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 a...
Building 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 "#...
Previously, 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 fo...
Previously, 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/fips14...
A malicious GOPROXY was previously capable of forging up to two sumdb tiles that allow for a requested module to bypass the GOSUMDB check and persist attacker-controlled module content to a local Go module cache. This attack allows for a malicious GOPROXY to serve malicious modul...
A malicious GOSUMDB was capable of serving arbitrary module content not contained within the transparency log. This attack allows for a coordinating GOPROXY and GOSUMDB to serve a client malicious module content that cannot be detected by evaluating the transparency log. In order...
A malicious module proxy can exploit a flaw in the go command's validation of module checksums to bypass checksum database validation. This vulnerability affects any user using an untrusted module proxy (GOMODPROXY) or checksum database (GOSUMDB). A malicious module proxy can ser...
The "go bug" command writes to two files with predictable names in the system temporary directory (for example, "/tmp"). An attacker with access to the temporary directory can create a symlink in one of these names, causing "go bug" to overwrite the target of the symlink.
The "go tool pack" subcommand (usually used only by the compiler as an internal tool with known-good inputs) does not sanitize output filenames. Extracting a malicious archive file with the "pack" subcommand can write files to arbitrary locations on the filesystem.
Arithmetic over induction variables in loops were not correctly checked for underflow or overflow. As a result, the compiler would allow for invalid indexing to occur at runtime, potentially leading to memory corruption.
SWIG file names containing 'cgo' and well-crafted payloads could lead to code smuggling and arbitrary code execution at build time due to trust layer bypass.
The compiler is meant to unwrap pointers which are the operands of a memory move; a no-op interface conversion prevented the compiler from making the correct determination about non-overlapping moves, potentially leading to memory corruption at runtime.
A discrepancy between how Go and C/C++ comments were parsed allowed for code smuggling into the resulting cgo binary.
Downloading and building modules with malicious version strings can cause local code execution. On systems with Mercurial (hg) installed, downloading modules from non-standard sources (e.g., custom domains) can cause unexpected code execution due to how external VCS commands are...
Building a malicious file with cmd/go can cause can cause a write to an attacker-controlled file with partial control of the file content. The "#cgo pkg-config:" directive in a Go source file provides command-line arguments to provide to the Go pkg-config command. An attacker can...
The go command may execute unexpected commands when operating in untrusted VCS repositories. This occurs when possibly dangerous VCS configuration is present in repositories. This can happen when a repository was fetched via one VCS (e.g. Git), but contains metadata for another V...
Sources: CVE.org, NVD, CISA KEV, FIRST EPSS, OSV and public exploit-reference metadata. Product matching comes from the published CVE records. A proof-of-concept means public code exists; it is not evidence of exploitation.