Skip to content
Hacker Posts

OpenCode flaw let malicious MCP servers run code on Windows

A hijacked remote MCP server could run PowerShell on a developer's machine during OpenCode sign-in on Windows/WSL. No CVE; fixed silently in 1.18.33. Pillar Security disclosed it October 19.

Published 3 min read
toolingai-securitymcpopencode

A malicious or hijacked remote MCP server could run arbitrary PowerShell on a developer's machine during OpenCode's sign-in flow on Windows and WSL, researchers at Pillar Security found. There is no CVE and the maintainer shipped no advisory, so scanners will not flag affected builds — the fix landed quietly in OpenCode 1.18.33. The primary sources are Pillar Security's disclosure (October 19), relayed by The Hacker News, and the v1.18.33 release notes, which list the fix as a bugfix without mentioning a security issue.

What the flaw does

When OpenCode authenticates to a remote MCP server over OAuth, the server supplies an authorization endpoint URL. OpenCode passed that address to the open helper package, which built a PowerShell command without escaping it. A server controlled by an attacker can hand back a string that is not a URL but a PowerShell command, and it runs on the developer's machine with the developer's access.

The trigger is narrow but realistic: the browser launch fires only when a user starts sign-in (opencode mcp auth or the equivalent request). Merely configuring the server or opening a session does not run the payload. macOS and Linux are not affected — this is a Windows/WSL command-construction bug.

Affected and fixed versions

  • Affected: OpenCode 1.0.137 through 1.18.32, on Windows and WSL.
  • Fixed: 1.18.33, released September 28. The release notes describe a change to MCP browser-launch behavior; the maintainer, Anomaly, says malicious MCP servers fall outside its threat model.

Pillar Security reported the issue privately on August 29 and disclosed on October 19, assigning a proposed CVSS-style score of 9.8. Pillar reported no signs of exploitation and published no indicators of compromise.

Action checklist

  1. Upgrade to OpenCode 1.18.33 or later on Windows and WSL developer machines.
  2. If you cannot upgrade yet, remove unvetted remote MCP servers from your configuration — the attack requires a server you authenticate to.
  3. Enumerate what is configured with opencode mcp list and treat any remote server you did not stand up yourself as untrusted.
  4. Prefer HTTPS-only connections to trusted MCP servers, and avoid initiating OAuth sign-in to servers you cannot vouch for.

Context

This is the same failure mode that has hit MCP client after MCP client in 2026: an attacker-controlled OAuth authorization_endpoint reaching an unsanitized browser-launch call. It is the identical root cause behind CVE-2025-6514 in mcp-remote (CVSS 9.6), CVE-2025-61591 in Cursor, and CVE-2025-58062 in the openmcp-client VS Code plugin — all tracing back to the widely used open library passing endpoint URLs to a shell-interpretable path on Windows. The pattern is now well enough established that any agent or client which launches a browser from a server-supplied URL should be treated as suspect until it proves it sanitizes that input. That OpenCode shipped the fix as an unmarked bugfix, rather than an advisory with a CVE, is the practitioner's problem here: there is nothing for a scanner to key on, so the only defense is tracking the version and vetting the MCP servers you sign in to.

Related stories