CVE-2022-30580

What it actually does

This vulnerability affects Go programs built with vulnerable Go toolchains before Go 1.17.11 and Go 1.18.3 that use os/exec.Cmd with Cmd.Path unset and invoke Cmd.Run, Cmd.Start, Cmd.Output, or Cmd.CombinedOutput. Under the vulnerable behavior, command resolution can cause a binary located in the process working directory and named "..com" or "..exe" to be executed unexpectedly. The flaw is a local code-injection/command-execution issue: an attacker who can place files in the working directory used by an affected Go application may cause that application to execute attacker-controlled code with the privileges of the Go process.

Why it matters to the business

Successful exploitation can turn a file-write or working-directory manipulation opportunity into execution of malicious code inside an application or automation process. Depending on the privilege level of the affected Go program, this can lead to data theft, tampering, lateral movement, service disruption, or compromise of build, deployment, or operational workflows. The issue is not known to be in the CISA Known Exploited Vulnerabilities catalog and has low EPSS scoring, but it remains important for software supply-chain hygiene because vulnerable Go-compiled applications may persist long after the toolchain was fixed.

How an attack unfolds

An attacker first needs local access or another vulnerability that lets them create files in a directory that an affected Go application later uses as its working directory. The attacker places a malicious executable named "..com" or "..exe" in that directory. When the vulnerable Go application constructs an exec.Cmd without explicitly setting Cmd.Path and then calls Run, Start, Output, or CombinedOutput, the vulnerable command-resolution behavior may execute the attacker-controlled binary from the working directory. The malicious binary then runs with the same operating-system permissions, environment, file access, and network reachability as the affected Go process. Exploitation is most relevant where Go programs operate on attacker-controlled directories, temporary directories, extracted archives, shared workspaces, CI/CD workspaces, or writable service directories.

How to fix it

Rebuild and redeploy affected Go applications using a fixed Go release: Go 1.17.11 or later in the 1.17 line, Go 1.18.3 or later in the 1.18 line, or any currently supported newer Go release. For source-based tracking, the Go project fix is represented by commit 26cdea3acca29db94541236f0037a20aa22ce2d7. Because this is a toolchain/runtime library issue, updating the Go compiler alone is not enough for already-built binaries; affected applications must be rebuilt with the fixed toolchain and redeployed. As defense in depth, review Go code that uses os/exec and explicitly set the intended executable path, avoid running commands from attacker-writable working directories, sanitize or isolate temporary/extraction directories, and ensure service working directories are not writable by untrusted users.

How to confirm the fix worked

Inventory Go toolchain versions used in build pipelines and developer images with `go version`; confirm builds use Go 1.17.11, Go 1.18.3, or later. Identify deployed Go binaries and, where possible, inspect embedded build information using `go version -m <binary>` to determine the Go version used to compile them. Confirm affected applications have been rebuilt after the toolchain upgrade rather than only patching build hosts. Review code for uses of `os/exec.Command`, `exec.Cmd`, `Cmd.Run`, `Cmd.Start`, `Cmd.Output`, and `Cmd.CombinedOutput`, especially where the process working directory can be influenced by users, archives, jobs, plugins, or shared workspaces. Validate filesystem permissions so untrusted users cannot create `..com` or `..exe` in application working directories. Where safe, test in a controlled environment by placing a benign marker executable with the affected name in a writable working directory and verifying the rebuilt application does not execute it unexpectedly.

Typical attack path

1. Gain local authenticated access, compromise a lower-privileged process, or abuse an upload/extraction/workspace feature that permits file creation in a directory used by a Go application.
2. Create or stage a malicious executable named "..com" or "..exe" in the target working directory.
3. Wait for or trigger the vulnerable Go application to execute a command using os/exec with Cmd.Path unset through Cmd.Run, Cmd.Start, Cmd.Output, or Cmd.CombinedOutput.
4. The vulnerable command-resolution behavior launches the attacker-controlled executable from the working directory.
5. Use the process privileges to read or modify data, establish persistence, access credentials, disrupt operations, or pivot to other systems.

How to detect it

To determine whether exploitation already occurred, review endpoint telemetry and operating-system logs for creation or execution of files literally named "..com" or "..exe". Focus on directories used by Go applications, services, agents, CI/CD runners, temporary processing locations, upload directories, extracted archives, and shared workspaces. Useful data sources include EDR process creation events, Sysmon Event ID 1 process creation, Sysmon Event ID 11 file creation, Windows Security process creation event 4688 if command-line auditing is enabled, Linux auditd execve records, shell history where relevant, file integrity monitoring, application logs that record working directories or spawned commands, and CI/CD job logs. Investigate parent processes that are Go binaries or applications compiled with Go, especially where the child process image path ends in `\..com`, `\..exe`, `/..com`, or `/..exe`. Also inspect for post-exploitation behavior after such execution, including unusual child processes, credential access, outbound connections, persistence changes, or modification of application data. Absence of these artifacts does not prove non-exploitation if process/file telemetry was not retained at the time of activity.

• ..com
• ..exe
• \\..com
• \\..exe
• /..com
• /..exe
• Image|endswith:\\..com
• Image|endswith:\\..exe
• Image|endswith:/..com
• Image|endswith:/..exe
• TargetFilename|endswith:\\..com
• TargetFilename|endswith:\\..exe
• TargetFilename|endswith:/..com
• TargetFilename|endswith:/..exe
• go version go1.17
• go version go1.18

What your security team should do

• Prioritize identifying Go applications built with Go versions earlier than 1.17.11 or 1.18.3, especially services, agents, CI/CD tools, file-processing systems, and automation that execute external commands.
• Upgrade build environments to fixed or current supported Go releases and require rebuilding/redeploying statically compiled Go binaries.
• Search source code for os/exec usage where Cmd.Path may be unset or command execution occurs from user-writable working directories.
• Harden application working directories, temporary directories, extracted archive locations, and CI/CD workspaces to prevent untrusted creation of executables named "..com" or "..exe".
• Add detection logic for suspicious creation or execution of files named "..com" and "..exe", especially under service directories, temporary paths, build workspaces, upload directories, and extracted archives.
• If suspicious files or executions are found, perform incident response scoping around the parent Go process, associated user account, working directory contents, child processes, network connections, and credential access.