Vulnerabilities

OpenCode, the open-source AI coding agent from Anomaly, had a command injection flaw in how it signs in to remote Model Context Protocol (MCP) servers. MCP is the protocol coding agents use to connect to outside tools and data. On Windows and Windows Subsystem for Linux (WSL), versions 1.0.137 through 1.18.32 let a malicious or hijacked remote MCP server run code on the developer's machine during the OAuth sign-in, with the developer's own rights. Pillar Security researcher Eilon Cohen published the details on October 19. macOS and Linux installs are not affected.

Anomaly fixed it in 1.18.33 on September 28, but did not request a CVE and did not publish a security advisory. Vulnerability scanners and dependency alerts key off CVEs, so they will not flag the old builds. If developers on your team run OpenCode on Windows or under WSL, the only way to know whether they are exposed is to check the version on each machine.

How it works

Remote MCP servers can require OAuth sign-in. When a server answers a request with HTTP 401, OpenCode starts the OAuth flow, as its own documentation describes. Part of that flow is a discovery document the server publishes, and its authorization_endpoint field tells the client where to send the user to log in. That field is a free-form string chosen by the server, and according to Pillar, OpenCode neither checked its scheme nor compared it with the origin of the server the developer had configured.

OpenCode then opened that address in the default browser using open, a widely used npm package that launches files and URLs. On Windows, the release OpenCode used built a PowerShell command around the URL without escaping it. A URL that looks like an ordinary https:// address but carries PowerShell syntax therefore gets that syntax executed. Pillar's write-up gives the detail: PowerShell expands $(...) subexpressions inside double-quoted strings, so the injected command runs even though the browser launch then fails, and OpenCode silently ignored that failure. The sources do not explain the WSL path in detail, only that WSL installs are affected.

On macOS and Linux, open starts the browser directly and passes the URL as a separate argument, so no shell ever parses it. That is why only Windows and WSL are in scope.

The Windows behaviour of open had been reported as a command injection risk in 2023 and fixed in the package's version 11, but OpenCode stayed on an older release. The same pattern hit mcp-remote, a proxy that connects MCP clients to remote servers, in July 2025 as CVE-2025-6514 (CVSS 9.6, fixed in 0.1.16).

Pillar points out that checking the URL scheme does not stop this, because the malicious address is a valid HTTPS URL. Anomaly added scheme checks in 1.18.33, but Pillar says the change that actually closes the hole is the move to a fixed open release, which quotes the URL properly.

What has to happen for an attack

The attacker needs control of a remote MCP server the developer has added. It does not have to be malicious on the day it is added: Pillar lists a server compromised later, a hijacked registry entry, a typosquatted name and an expired domain someone re-registers.

The sources differ on how much the developer has to do. Pillar and Infosecurity Magazine say the code runs with no extra user interaction or consent once the OAuth handshake starts. The Hacker News reports that it runs only when the developer starts sign-in, for example with opencode mcp auth, and that adding a server or opening a session alone does not trigger it. In practice, sign-in is a routine step the first time anyone uses an OAuth-protected server, so treat it as something that will happen.

Severity and the vendor's position

Pillar rates the flaw critical with a proposed CVSS 3.1 score of 9.8. It reported the issue privately through a GitHub Security Advisory on August 29. Anomaly confirmed receipt about a month later and replied that it had "updated the dependency, but generally, trying to deal with a malicious MCP server is outside our threat model." The fix shipped as a refactor of browser-launch code, and neither the pull request nor the release notes mention security. Pillar asked Anomaly to reconsider and request a CVE; none has been issued.

Neither Pillar nor the news coverage reports exploitation in the wild, and no indicators of compromise have been published.

This is a separate issue from the OpenCode Console breach that exposed stored provider API keys. Cohen confirmed the two are unrelated.

What to do

1. Find every install and its version

Run opencode --version (or opencode -v) in PowerShell and inside each WSL distribution separately, because a WSL install is its own copy. Any version from 1.0.137 to 1.18.32 is exposed. Because there is no CVE, your software inventory or endpoint management tool is the place to search: look for the opencode-ai npm package and for opencode binaries in user profiles, since developers often install AI tools without a ticket.

2. Upgrade to 1.18.33 or later

Run opencode upgrade, which moves to the latest release. If OpenCode was installed through npm, pnpm or bun, the --method option tells the upgrader which one to use, or you can update through that package manager directly. Run opencode --version afterwards to confirm.

3. Audit the configured MCP servers

opencode mcp list shows each configured server and its sign-in status, and opencode mcp auth list narrows that to the servers using OAuth. Servers live under the mcp key in the config files, which OpenCode merges: the global ~/.config/opencode/opencode.json, a project opencode.json found from the current directory up to the Git root, any file named in the OPENCODE_CONFIG environment variable, and managed config under %ProgramData%\opencode on Windows. Run opencode debug paths config to see which path applies. Every entry with "type": "remote" is a server that could start this flow. For each one, confirm who runs it, that the domain is still theirs, and that the team still needs it.

4. If you cannot upgrade today

Pillar's advice for Windows and WSL users who cannot upgrade is to remove unvetted remote MCP servers from the config until they can. You can set "enabled": false on an entry or delete it.

5. Check for signs of use

No indicators exist, so the useful places to look are process and PowerShell records on developer machines. Pillar's write-up says the old open release launched PowerShell with -EncodedCommand, so every OAuth sign-in on a vulnerable build created a PowerShell child process of OpenCode. In your endpoint detection tool, or Sysmon Event ID 1, review powershell.exe processes whose parent is OpenCode and decode the command lines. With script block logging on, Event ID 4104 in Microsoft-Windows-PowerShell/Operational records the decoded script. Anything beyond starting a browser with a login URL deserves a closer look. If you find one, treat the machine as compromised and rotate what the developer's account could reach: Git and cloud credentials, API keys in the OpenCode config and the OAuth tokens OpenCode stored for its MCP servers.

The wider lesson

AI coding agents talk to third-party servers with the developer's rights, and when a vendor fixes a flaw quietly, the CVE feeds that drive patching stay silent. Teams need an inventory of which agents developers run, which MCP servers those agents connect to, and a way to update them that does not depend on an advisory.

Our safeguarding and hardening work covers developer workstations and the tools on them, and our red team code review looks at how in-house tools handle data from servers they do not control. Open the chat and Yaali, our AI agent, will pass your question to the engineer who would do the work.

---

Sources: Pillar Security, The Hacker News, Infosecurity Magazine, OpenCode MCP servers documentation, OpenCode CLI documentation, OpenCode config documentation, Cyber Security News on CVE-2025-6514.