OpenCode MCP Flaw Enabled Code Execution at Sign-In With No CVE

A login link that ran PowerShell

OpenCode is an open-source AI coding agent maintained by a company called Anomaly. Until late September, a remote Model Context Protocol (MCP) server could use it to run arbitrary code on a developer's Windows or WSL machine during OAuth sign-in, and that code would run with the developer's own privileges.1 Pillar Security found the bug. The firm proposes a critical severity score of 9.8 and says versions 1.0.137 through 1.18.32 are affected. Version 1.18.33, published on September 28, 2026, fixes it.12

The patch is only half the story. Anomaly did not request a CVE or publish a security advisory, so vulnerability scanners and dependency bots have no record to match against. Builds that are still exposed will not be flagged automatically.8 For a tool Pillar says gets about 3 million weekly npm downloads, the lack of a record is probably a bigger long-term risk than the bug itself.

How the attack worked

The weak point was a field most developers never see. When an MCP client signs in to a remote server over OAuth, the server provides its own "authorization endpoint," which is the address the user's browser gets sent to.11 Pillar followed that value from the server's discovery document through the MCP SDK and OpenCode's OAuth code to a small npm package called open, which launches the browser. At no point was the URL's scheme checked or compared with the origin of the server the developer had configured.5

On Windows, every affected OpenCode release pinned version 10.1.2 of open. That version builds a PowerShell command, base64-encodes it and runs it with -EncodedCommand. The application name gets escaped, but the target URL does not.5 PowerShell evaluates $(...) subexpressions inside double-quoted strings, so a crafted address runs its embedded command first. The browser launch then fails, and OpenCode throws away the error.5 macOS and Linux are not affected because open passes the address as an argument there and no shell reads it.1

The exploit used a perfectly valid https:// address. That is why the usual defence for this kind of bug, allowing only HTTP and HTTPS schemes, would not have stopped it.1 Forkast notes that the MCP SDK's blocklist of javascript:, data: and vbscript: lets the payload through, and so does the scheme check OpenCode added in its own patch. The fix that actually closed the hole was upgrading to open 11.0.4, which puts the target in single quotes. PowerShell does not expand anything inside single quotes.4

The trust problem at the centre of MCP

The server did not have to be malicious when the developer added it. Pillar notes that the payload arrives in an HTTP response at connection time. A server compromised later, a hijacked registry entry, a typosquat or an expired domain could all set off the same chain.12 The Hacker News makes the same point: a domain that changes hands could serve the poisoned address.1

This is the key detail for anyone managing MCP risk. Teams usually treat adding a server as a one-time vetting decision. This flaw shows that trust has to hold every time the client talks to the server. Anomaly's security policy takes the opposite position: it says user-configured MCP servers are "outside our trust boundary."1 According to Pillar, the company told researchers that a malicious MCP server falls outside its threat model.3

That position makes sense for some threats. A malicious server feeding an agent bad tool output is hard for any client to defend against. This case is different. Here the client itself turned a server-supplied string into a shell command on the host. Pillar contrasts OpenCode with gemini-cli, Claude Code, github-mcp-server and Docker's mcp-gateway, which it says pass the URL as an argument and never build a shell command from it.5 Calling the server untrusted does not excuse a client for executing its input.

A known bug, repeated

The ecosystem had already seen this exact bug. In July 2025, the mcp-remote proxy had a nearly identical flaw in which a malicious server's authorization endpoint reached the command line. It was assigned CVE-2025-6514.1 Forkast lists two more in 2025: CVE-2025-58062 in openmcp-client and CVE-2025-10619 in sequa-mcp.4 Pillar adds that OpenCode's vulnerable code was written in December 2025, months after the first of those disclosures.12

The history of the open package goes back even further. Pillar traces it to an issue filed in October 2020, which reported that URLs containing a dollar sign broke on WSL 2.12 An issue titled "OS command injection on windows when opening urls" was opened in October 2023 and closed as "not planned" in November 2025. Days later, open v11.0.0 shipped with a PowerShell escaping fix.3 OpenCode added its OAuth browser call in December 2025 but stayed on the older 10.x release.31

The lesson for anyone building MCP clients is that a dependency's changelog can be a security notice even when nobody labels it as one.

A quiet fix, a disputed severity

The disclosure timeline is not seriously disputed. Pillar filed a private GitHub Security Advisory with reproduction material on August 29. On September 25 Anomaly confirmed it had the report, and a pull request titled as a refactor of browser-opening code was merged the same day. Version 1.18.33 followed three days later.5 The release notes mention MCP browser-launch failure reporting but say nothing about security.3 Anomaly published an unrelated high-severity advisory on September 24, which shows it does use the advisory process for other issues.3 The Hacker News also notes advisories for other OpenCode code-execution flaws this year.1

Pillar gives Anomaly credit for a substantial technical fix while criticising the missing security notice.9 By OrcaRouter's account, the fix had three layers: the dependency bump, a new helper that rejects non-HTTP(S) schemes, and a scheme check inside the authorization redirect.5 The engineering was sound. The disclosure was not.

The main disagreement between accounts is about user interaction. Pillar says exploitation needs no interaction or consent beyond the OAuth connection.2 The Hacker News says the vulnerable step only runs when a developer starts sign-in, for example with opencode mcp auth, and that just configuring a server or opening a session does not trigger it.1 Safeguard adds that OpenCode's documentation describes the OAuth flow starting automatically when a server returns HTTP 401, with a prompt on first use. By Safeguard's calculation, scoring with user interaction required gives about 8.8.3 OrcaRouter notes that the Cloud Security Alliance reached the same figure.5 The related mcp-remote CVE was scored with interaction required.3

The more cautious reading is the better one. Some user action probably starts the chain, so 9.8 likely overstates it. But 9.8 versus 8.8 makes little practical difference. Either score means remote code execution on a developer workstation, which usually holds source code, cloud credentials and API keys.

Not the Console breach

The disclosure landed in a bad week for OpenCode. Around the same time, the company disclosed an intrusion into a legacy system behind its hosted Console. That breach may have exposed stored API keys for OpenAI, Anthropic and Google.1 OpenCode says about 1.4% of Console users were affected.3 The two incidents are unrelated. A Pillar researcher described the breach as hitting a hosted key proxy, while the MCP flaw runs the other way, from a remote server onto the developer's own machine.2 No exploitation of the MCP flaw has been reported and no indicators of compromise have been published.1

What defenders should do

There is no identifier to match, so finding affected installs means checking manually. Pillar advises security teams to inventory OpenCode directly. Any version from 1.0.137 to 1.18.32 on a Windows or WSL host is exposed.12 Safeguard suggests running opencode mcp list to review configured remote servers.3 Forkast recommends removing unvetted remote MCP servers until the upgrade is done and confirming that open is at 11.0.4 or later.4

The broader warning applies to any MCP client that opens a server-supplied authorization URL through a shell on Windows. Safeguard notes the bug class has now appeared in at least two MCP clients.3 With remote MCP servers multiplying, every sign-in passes server-controlled data to the host. Clients need to treat that data as untrusted. When they fix a flaw like this, they should say so publicly, because developers can't patch something nobody has told them about.