A critical command injection vulnerability in the OpenCode AI developer assistant allows remote or hijacked Model Context Protocol (MCP) servers to execute arbitrary shell code on developer workstations running Windows and the Windows Subsystem for Linux (WSL). By crafting a malicious OAuth authorization endpoint, an untrusted MCP server can escape URL parsers and execute system binaries with the permissions of the authenticated developer session.
OpenCode maintainer Anomaly resolved the underlying injection path in release v1.18.33 following coordinated vulnerability disclosure from security research firm Pillar Security. However, Anomaly did not request a Common Vulnerabilities and Exposures (CVE) identifier or publish a formal security advisory, maintaining in its trust specification that user-configured MCP integrations remain outside its security boundary. Consequently, automated software composition analysis (SCA) tooling and vulnerability databases will fail to flag unpatched enterprise installations spanning versions 1.0.137 through 1.18.32.
The Architecture of MCP Integrations in Autonomous Coding Agents
The Model Context Protocol, pioneered by Anthropic and broadly adopted across autonomous developer agents, standardizes bidirectional remote procedure call (RPC) communications between language models and external tool environments. Developers incorporate MCP servers to expand their agent's reach into file systems, database consoles, private code repositories, and SaaS platforms.
When an MCP server requires third-party API credentials, it initiates an OAuth 2.0 authorization handshake. Under the specification, the remote server issues a redirect payload instructing the local client agent to launch the developer's default web browser and navigate to an external identity provider (IdP). The developer authenticates via the browser, which then redirects to a local loopback handler to deliver the short-lived authorization token back to the agent session.
In OpenCode, this browser-launch mechanism delegated execution to a third-party helper dependency. While POSIX systems handle desktop process creation via direct kernel exec calls (such as xdg-open on desktop Linux or open on macOS), the Windows dispatch engine relied on an unescaped command-line wrapper.
Vulnerability Mechanics: PowerShell Injection via the 'open' Package
The technical root cause resides in OpenCode's reliance on legacy releases of the popular Node.js package open (specifically versions preceding v11.0.0). When instructed to spawn a browser window on Windows or within a WSL environment, the package constructed an inline PowerShell command:
# Vulnerable command construction logic in legacy open wrappers
powershell.exe -NoProfile -NonInteractive -Command Start-Process "$TARGET_URL"
Because the URL argument was concatenated directly into the shell string without sanitization or parameter binding, metacharacters such as ampersands (&), semicolons (;), and subshell execution delimiters ($()) were interpreted by PowerShell. When a developer executed the interactive authentication command:
opencode mcp auth <server-name>
The OpenCode client queried the target MCP server's metadata endpoint. If the server returned an authorization URL containing embedded PowerShell syntax, such as:
https://auth.example.com/oauth/authorize?client_id=123";Start-Process calc.exe;#
The PowerShell interpreter terminated the Start-Process argument, evaluated the injected statement, and commented out the remainder of the generated script block. The secondary payload executed immediately in the background with full interactive user privileges, bypassing URL scheme validations that merely verified the https:// prefix.
Why macOS and Native Linux Environments Remain Immune
The vulnerability strictly impacts Windows hosts and WSL virtual environments. On macOS, OpenCode utilizes the Darwin /usr/bin/open binary, which passes target URIs as discrete array arguments without intermediate shell interpretation. Similarly, Linux implementations invoke xdg-open via direct POSIX execve() calls, where metacharacters are treated as literal URL string characters rather than control directives.
Comparative Vulnerability Analysis: Echoes of CVE-2025-6514
The architectural pattern mirrors CVE-2025-6514, a critical remote code execution vulnerability discovered in July 2025 within the mcp-remote proxy wrapper. In that incident, untrusted OAuth endpoints supplied by malicious proxy brokers were similarly passed directly to shell execution helpers.
| Vulnerability Attribute | OpenCode MCP OAuth Injection (2026) | mcp-remote Proxy Injection (CVE-2025-6514) |
|---|---|---|
| Vulnerability Class | CWE-78: OS Command Injection / CWE-94 | CWE-78: OS Command Injection |
| CVSS Base Score | 9.8 (Critical) | 9.8 (Critical) |
| Attack Vector | Malicious OAuth URL via opencode mcp auth |
Malicious OAuth redirect via proxy discovery |
| Vulnerable OS | Windows 10/11, Windows Server, WSL | Windows, Linux, macOS (All platforms) |
| Upstream Dependency | open < v11.0.0 |
Custom child_process shell concatenation |
| Catalog Status | Unassigned (Vendor policy dispute) | Assigned (NIST NVD / MITRE CVE) |
The AI Agent Trust Boundary Dilemma
The disclosure has renewed debate across the engineering community regarding trust boundaries in generative AI ecosystems. Anomaly's rationale for bypassing the CVE framework centers on the argument that adding an external MCP server constitutes an explicit administrative action, equating external tools to third-party dependencies.
However, threat intelligence analysts emphasize that MCP servers are increasingly distributed across public registries, developer hubs, and shared repository configuration files (such as opencode.json checked into collaborative source control). A developer cloning an open-source repository containing a trojaned or abandoned MCP server configuration needs only to initiate an authentication check to suffer full workstation compromise.
Defensive Playbook and Verification Guide
Organizations employing OpenCode within enterprise engineering teams must execute the following remediation and audit measures:
1. Verify Installed OpenCode Runtime
Inspect local agent builds across all developer workstations and CI runners:
# Check current OpenCode CLI build version
opencode --version
Ensure the installed version reflects v1.18.33 or higher. If the environment reports any build within the range 1.0.137 through 1.18.32, immediately initiate an update:
# Upgrade OpenCode to patched release
npm install -g opencode@latest
2. Audit Active MCP Server Registrations
Inspect all configured external servers to ensure credentials and network channels are established exclusively with verified corporate infrastructure:
# List all active MCP configurations
opencode mcp list
# Remove any unverified, community, or third-party remote endpoints
opencode mcp remove <untrusted-server-name>
3. Enterprise Endpoint Detection Queries
Security Operations Center (SOC) teams should hunt for anomalous child processes spawned by opencode.exe or Node.js parent processes executing PowerShell commands containing URL strings:
// EDR Detection Logic: Hunting OpenCode child process anomalies
DeviceProcessEvents
| where InitiatingProcessFileName in~ ("opencode.exe", "node.exe")
| where FileName in~ ("powershell.exe", "pwsh.exe", "cmd.exe")
| where ProcessCommandLine has_any ("Start-Process", "http://", "https://")
| project Timestamp, DeviceName, InitiatingProcessFileName, ProcessCommandLine
As autonomous coding assistants assume deeper integration into enterprise development cycles, security teams must treat external tool protocols with identical zero-trust rigor applied to production APIs and code registries.



