- Pillar Security says OpenCode on Windows and WSL could run code from a malicious MCP server during sign-in. Anomaly fixed it in version 1.18.33 without a CVE or advisory.
- Scanners and dependency alerts have nothing to match, so affected installs, versions 1.0.137 through 1.18.32, are found only by checking them directly.
- Teams should inventory OpenCode on Windows and WSL, upgrade, and review which remote MCP servers their coding agents trust.
A vulnerability scanner can warn you only about what someone chose to write down. A recent flaw in the OpenCode coding agent shows how large that gap can be. Pillar Security found that a remote server could run code on a developer's Windows machine during a routine sign-in. The vendor fixed it. No advisory or CVE was published for a scanner to match.
What Pillar Security found
OpenCode is an open-source AI coding agent. By Pillar's count, it draws around 3 million npm downloads each week and has 211,000 stars on GitHub. Like other coding agents, it works with the developer's own privileges. It can read files and run commands.
Pillar found that an attacker-controlled remote MCP server could execute code on the developer's machine during sign-in. MCP, the Model Context Protocol, is how agents connect to outside tools and services. Pillar says the attack needed no additional user interaction or consent beyond the sign-in itself. The Hacker News adds that a developer must start that sign-in, for example by running opencode mcp auth. Merely configuring a server does not set it off.
The attack did not need malware to be installed, a trick on the AI model, or prompt injection.
Only Windows is exposed, along with its Linux layer, the Windows Subsystem for Linux (WSL). Pillar lists the affected versions as 1.0.137 through 1.18.32. macOS and Linux are not affected.
How a login page became a command
When an MCP server wants a user to sign in, the client starts an OAuth handshake. OAuth is the standard behind "sign in with" buttons. The server tells the client which web address to send the user to. That address, the authorization endpoint, is a free-form string chosen by the server.
OpenCode passed that string to a helper package called open, which launches browsers. Pillar explains that on Windows, open 10.1.2 places the address inside a PowerShell command and leaves it unescaped. PowerShell evaluates anything written as $(...) inside double quotes. The embedded code runs even though the browser launch then fails.
Pillar also notes the server need not be hostile when added. The payload arrives in a response at connection time. A later takeover, a typosquat or an expired domain could deliver it.
Why the standard defense did not work
After CVE-2025-6514, a similar bug in the mcp-remote proxy, the usual advice was to check the URL scheme and allow only http and https. Pillar's payload is an ordinary https address with no spaces. It passes that check. It also passes the MCP TypeScript SDK's denylist, which blocks javascript:, data: and vbscript:, and the scheme check OpenCode added.
What closed the hole, Pillar says, was upgrading open to version 11.0.4, which wraps the target in single quotes. PowerShell expands nothing inside single quotes. Pillar's lasting guidance for people who build MCP clients is to hand URLs to the operating system as separate arguments, and to keep remote text out of any shell command line.
A known problem that stayed pinned
Pillar traces a long history. A 2020 issue on the open repository reported that URLs containing a dollar sign broke on WSL 2. It was filed as a cosmetic bug. In October 2023 an Adobe engineer reported command injection on Windows. The maintainer pointed to the README, which since 2021 has disclaimed security guarantees. The escaping fix landed in open 11.0.0 on November 15, 2025.
OpenCode added its call to open on December 7, 2025, still pinned to the older 10.1.2. Pillar does not call this negligence. It says this is simply what dependency pins do. Two other CVEs, CVE-2025-58062 and CVE-2025-10619, hit the same weakness in other MCP clients in 2025.
The vendor's threat model decided what you could see
Anomaly, OpenCode's developer, fixed the issue in 1.18.33 on September 28. According to Pillar, the fix was described as a refactor, and neither the pull request nor the release notes mention security. Anomaly requested no CVE. Its answer to Pillar was that malicious MCP servers are outside its threat model. The Hacker News reports that its security policy calls user-configured servers "outside our trust boundary."
Pillar's point is that anyone reading the code difference between 1.18.32 and 1.18.33 can reconstruct the bug. Defenders who rely on scanners and dependency alerts get no signal. The Hacker News reports that Pillar saw no signs of attacks and published no indicators for checking past exploitation.
The lesson here is about who decides what counts as a vulnerability. When a vendor places an input outside its threat model, your tooling inherits that decision. An MCP client reads data from a remote party, much like a browser or mail program. Treating the server as trusted is a business choice, not a technical fact.
What to ask your team
First, ask who runs OpenCode on Windows or WSL, and which version. Pillar says finding it means inventorying the tool directly. Upgrade to 1.18.33 or later. If that is not possible, Pillar advises removing unvetted remote MCP servers from the configuration.
Second, ask which remote MCP servers your coding agents trust, and who approved each one. A server that was safe when added can change hands.
Third, ask how your teams track agent tools that publish no advisory. A list kept by hand is a start. Check it against actual version numbers or code diffs, not release notes alone. This fix was described as a refactor, so its notes said nothing about security.
Last, ask vendors of AI developer tools where they draw the line on untrusted servers. The answer tells you which risks your scanners cannot report.
Produced by the WebPulse Newsroom with AI assistance from the original reporting credited below, and checked against that source by our editorial review. How we use AI.
Original reporting: Pillar Security.
