OpenCode versions 1.0.137 through 1.18.32 on Windows and WSL let a remote MCP server run commands on the developer's machine while the agent opened a browser for OAuth sign-in. Pillar Security reported the bug privately in late August 2026. The vendor, Anomaly, shipped a fix in version 1.18.33 on September 28, 2026, without a security advisory or a CVE. The OpenCode flaw is a command injection in a browser-launching dependency, and it is reachable from an attacker-controlled field in a normal MCP OAuth handshake.
If you run OpenCode on Windows or in WSL, update to 1.18.33 or later and review which remote MCP servers you have connected. Because there is no CVE, your dependency scanner will probably say nothing. This post walks through the chain, what is confirmed, and how to check your machines.
TL;DR
| Question | Answer |
|---|---|
| Am I affected? | OpenCode (opencode-ai on npm) 1.0.137 to 1.18.32 on Windows or WSL, if you sign in to a remote MCP server |
| macOS or Linux? | Pillar says not affected |
| Is there a fix? | Yes: 1.18.33, published 2026-09-28 |
| Is there a CVE? | No. Pillar proposes CVSS 3.1 9.8 (Critical), its own assessment |
| What triggers it? | Running the MCP OAuth sign-in against a malicious or later-compromised remote server |
| Does data leave my machine? | Code execution on the host means an attacker could read what the user can read; the reports do not describe a specific data theft |
| Seen in the wild? | Not shown; the write-ups describe a proof of concept |
What happened
Pillar Security's research, "Open and Shut: Remote Code Execution in opencode via MCP OAuth", describes a flaw where a string controlled by a remote MCP server reaches a Windows shell. Infosecurity Magazine, reporting on the disclosure, attributes the finding to Eilon Cohen of Pillar Security and says OpenCode has more than 218,000 GitHub stars. Pillar's own timeline lists the private report on August 29, 2026, the vendor's reply on September 25 that a malicious MCP server is "outside our threat model", the fix merge the same day, and release 1.18.33 on September 28. The dates for public disclosure differ between sources (Pillar's timeline says October 4; Infosecurity says October 19), so treat the exact publication date as unsettled. The fix date and version are consistent.
Note also that this is unrelated to the OpenCode Console breach claim, which concerned provider keys held in a hosted key proxy. Pillar says the two are not connected.
How the attack works
Pillar Security's diagram of the attack path is in its original report.
The chain, as Pillar describes it:
- You configure a remote MCP server. When it requires authorization it answers with a
401and aWWW-Authenticatechallenge that points to its OAuth discovery documents. - The discovery document carries a free-form string. The
authorization_endpointfield is controlled by the server. - OpenCode passes that value to a browser launcher. It flows from the MCP SDK through OpenCode's OAuth provider and browser code into the
open()function. There is no scheme check and no comparison to the origin of the server you configured. - The
openpackage builds a PowerShell command. In version 10.1.2, which every affected OpenCode release pins, the app name is escaped but the target URL is not. - PowerShell expands
$(...). The arguments are base64-encoded and passed topowershell -EncodedCommand. PowerShell expands$(...)inside double-quoted strings before resolving the command, so the payload runs even though the browser launch then fails and OpenCode discards the error.
The example payload in the write-up is an ordinary https:// URL with a $(...) expression in the path, which writes a marker file as a harmless demonstration. It contains no spaces, so URL parsing does not percent-encode it and it looks like a normal https address. That matters because many defences check only that a URL starts with http or https.
Why only when you sign in
According to Pillar and the summaries of it, the dangerous step runs when OpenCode launches the browser for sign-in, such as through opencode mcp auth. Merely having a server in your configuration does not reach it, and neither does opening a session. The attack needs a remote server you have already added and then authenticate with.
A long-known sink
The open package's weakness is not new. Pillar's timeline shows a public issue on $ handling on WSL in 2020, a proof of concept reported in October 2023 that was closed as not planned, and several later CVEs on the same sink, including CVE-2025-6514 in mcp-remote. The pattern is the same each time: an OAuth metadata URL controlled by a server reaches a shell on Windows. Beam has covered a sibling credential-handling problem in the MCP TypeScript SDK OAuth credential leak, and the broader lesson that MCP content is untrusted input runs through our MCP security guide.
What the vendor did and did not do
Anomaly's stated position, as reported, is that dealing with a malicious MCP server is outside its threat model. The fix shipped as a refactor of browser-launch call sites in 1.18.33 with three layers: a bump of open to 11.0.4, a new helper that rejects non-http(s) schemes, and a scheme check in the redirect step. Pillar says the scheme checks alone would not have stopped its proof of concept, and that the dependency bump, which wraps the target in single quotes, is what closes the hole. Neither the pull request nor the release notes mention security, and no CVE was requested.
That is the practical problem. Without an advisory, tools that watch advisories will not warn people still on older builds.
Why this bug class keeps coming back
The OAuth flow for remote MCP servers asks a client to do something unusual for a developer tool: open a URL that a third party chose. Most clients treat that URL as inert text. On Windows, the launcher beneath them is not inert, because the URL is interpolated into a PowerShell command line, where $(...) has meaning even inside a quoted string. The result is that data from the network crosses into code without anyone writing an obviously unsafe line in the agent itself.
Three things make this worse for agents than for ordinary apps. First, developers add remote MCP servers quickly, often from a README or a chat message, and rarely revisit the list. Second, the sign-in step feels routine, so there is no moment of suspicion; the browser may simply fail to open, which looks like a glitch rather than an attack. Third, the code that runs does so as the developer, with access to repositories, SSH keys, cloud credentials and the tokens of other coding agents on the same machine. That is the same blast radius that made the LiteLLM credential stealer worth rotating secrets over.
There is also a trust-model point. The vendor's view, as reported, is that a malicious MCP server is out of scope. Pillar's counter is that a server you trusted yesterday may not be the one answering today, since domains lapse and registries change hands. Whichever position you take, a client that executes shell syntax from a remote metadata field is relying on every server it ever connects to staying honest.
What this means if you run AI coding agents
- Update OpenCode on Windows and WSL. Check the version with
opencode --version, ornpm ls -g opencode-aiif you installed through npm. Anything from 1.0.137 to 1.18.32 is affected; move to 1.18.33 or later. - Inventory installs yourself. Without a CVE, scanners and dependency bots will not flag this. Include developer laptops and WSL distributions, which are easy to miss.
- Audit remote MCP servers. Run
opencode mcp listand remove servers you do not recognize or no longer use. A server that was fine at configuration time can later be taken over, or its domain can change hands. - If you cannot update, do not sign in. Pillar's advice for the unpatched case is to remove unvetted remote servers; the exposure begins at the OAuth sign-in step.
- Look for signs, knowing the limits. Pillar offers no indicators of compromise. Its proof of concept writes
C:\Users\Public\pwned.txt, but a real attacker would not necessarily use that name. A reasonable extra step, which is our suggestion rather than Pillar's, is to review PowerShell logs for-EncodedCommandinvocations launched around a sign-in, and to rotate credentials on machines where you signed in to an MCP server you now distrust. - For your own tools, use argv launchers. If you build agents or MCP clients, do not construct a command line from remote strings. Pillar's summary of the fix is to use argument-based process execution, and to bind OAuth discovery to the origin of the configured server.
For comparison, the Cursor MCP config poisoning RCE shows the same lesson from another angle: files and metadata that an MCP server or repository controls should never reach a shell unchecked.
What Beam can and cannot do here
Beam does not install hooks for OpenCode. Its documentation lists OpenCode as config and artifact discovery only, with hook installation not implemented. That means Beam cannot deny or record this attack's command on OpenCode the way it can for Claude Code and Codex PreToolUse hooks.
What Beam can do is limited but real. Its scanner reviews MCP configurations with heuristics, including a check for unpinned versions, which helps you see which servers an agent is set to use before you run it. That is inventory help for step 3 above, not detection of this bug: the scan is heuristic, not semantic analysis, and it will not tell you that a remote server's discovery document is malicious. Beam is not a kernel sandbox either. See what Beam watches and how it stays local. For general review steps, see how to review an MCP server.
Frequently asked questions
Which OpenCode versions are affected by the MCP OAuth flaw?
Pillar Security reports versions 1.0.137 through 1.18.32 of the opencode-ai npm package are affected on Windows and WSL. It says macOS and Linux are not affected. Version 1.18.33, published September 28, 2026, contains the fix.
Is there a CVE for this OpenCode vulnerability?
No. The vendor fixed it without a security advisory or CVE, and Pillar published its report without one. Pillar proposes a CVSS 3.1 score of 9.8, which is its own assessment. Because no CVE exists, dependency scanners and alerts may not flag older installs.
Do I have to be attacked by a server I just added?
The server has to be a remote MCP server you configured and then sign in to. Pillar notes it need not be malicious at configuration time: a later takeover, a hijacked registry entry, a typosquat or an expired domain could trigger the same path.
Does a scheme check stop the attack?
No. The payload is an ordinary https URL, so checking that a URL starts with http or https does not stop it. Pillar says the dependency upgrade to open 11.0.4, which quotes the target, is what closes the hole.
How do I check whether I am affected?
Find OpenCode installs on Windows and WSL machines and check the version, for example with npm ls -g opencode-ai or opencode --version. Anything from 1.0.137 to 1.18.32 is affected. Also list the remote MCP servers you have configured and remove ones you do not recognize.
Was this exploited in the wild?
Not that has been shown. The public write-ups describe a controlled proof of concept, and Pillar offers no indicators of compromise beyond inventory. Absence of evidence is not proof of safety, so patch and review your MCP server list.
Related reading
- Pillar Security: Open and Shut, Remote Code Execution in opencode via MCP OAuth
- Infosecurity Magazine on the quiet OpenCode patch
- Four advisories fixed in the MCP TypeScript SDK 1.32.0
Versions and dates reflect Pillar Security's report and press coverage as of October 22, 2026. Check the OpenCode release notes for the latest versions. Beam is a local prototype and its limits are described above.