Critical OpenCode RCE Was Patched as a ‘Refactor.’ No CVE Exists, So Nothing Flags It.

Anomaly patched a critical remote code execution flaw in its OpenCode AI coding agent inside a September 28 refactor of browser-launch code, published no security advisory and requested no CVE, leaving every installation below version 1.18.33 exposed without a scanner alert, according to Pillar Security's report on the roughly 3-million-weekly-download npm package. The flaw, rated CWE-78 command injection with CWE-88 argument injection and proposed by Pillar at CVSS v3.1 9.8 Critical, let a remote Model Context Protocol server run arbitrary code on Windows and Windows Subsystem for Linux during the OAuth handshake by placing a PowerShell $(...) payload in the free-form authorization_endpoint field, which flowed through the MCP SDK to the open browser launcher pinned at 10.1.2. The hole was closed only by bumping to open@11.0.4, which single-quotes the target URL; Pillar warned that "If you implemented scheme validation after reading about CVE-2025-6514 and you're still on open@10.x, you are not fixed.

A critical remote code execution flaw in OpenCode has been patched. The standard defender toolchain cannot see that. Anomaly, the developer of the open-source AI coding agent that Pillar Security’s report https://www.pillar.security/blog/open-and-shut-remote-code-execution-in-opencode-via-mcp-oauth puts at roughly 3 million weekly npm downloads and 211,000 GitHub stars, shipped the fix inside a refactor of browser-launch code on September 28, published no security advisory, and requested no CVE. Scanners and dependency alerts have nothing to match. Every installation below version 1.18.33 still needs the upgrade, and nothing is going to tell its owner. The flaw is remote code execution through the remote Model Context Protocol https://forkast.news/glossary/model-context-protocol-mcp/ OAuth authentication flow on Windows and Windows Subsystem for Linux. A remote MCP server executes arbitrary code on the developer’s own machine during the handshake, with no additional user interaction and no model consent. Nothing gets installed and no model gets tricked, so this is not prompt injection. The server answers the client’s authentication request with its own discovery documents, and one field in them, authorization endpoint, is a free-form string the server picks. In versions 1.0.137 through 1.18.32, that value flowed straight to a shell. Pillar’s report gives the chain: server’s discovery doc → MCP SDK → oauth-provider.ts → mcp/index.ts → browser.ts → open → PowerShell The last hop is the open package https://github.com/sindresorhus/open , a browser launcher pinned at version 10.1.2 by every affected release. It escapes the application name before building the command line and leaves the target URL unescaped. PowerShell expands $ … subexpressions inside double-quoted strings, so the URL runs as code before the browser launch fails, and OpenCode discards the failure. Pillar’s example payload is https://evil.test/$ IO.File ::WriteAllText 'C:\Users\Public\pwned.txt','RCE' . The classification is CWE-78 command injection with CWE-88 argument injection behind it. Pillar proposes CVSS v3.1 at 9.8 Critical; there is no official score because there is no CVE. And the payload arrives in an HTTP response at connection time, so the server did not have to be malicious when it was configured. A later compromise, a hijacked registry entry, a typosquat, or an expired domain reaches the same path. The standard remedy does not stop it. The payload is an ordinary https URL, so the MCP SDK’s scheme denylist of javascript:, data:, and vbscript: waves it through, and so does the new scheme check OpenCode shipped alongside the fix. What closed the hole was a dependency bump to open@11.0.4, which wraps the target in single quotes; PowerShell expands nothing inside single quotes. Pillar’s line for anyone who hardened after the last one of these: “If you implemented scheme validation after reading about CVE-2025-6514 and you’re still on open@10.x, you are not fixed.” This is the third year of the same defect. CVE-2025-6514 rated 9.6 Critical in July 2025, same package, same OAuth field. CVE-2025-58062 followed in August 2025 against openmcp-client, and CVE-2025-10619 in September 2025 against sequa-mcp. OpenCode’s vulnerable line was written on December 7, 2025, three weeks after open@11.0.0 shipped the escaping fix on November 15. The open package’s tracker had reported the expansion in October 2020 as a broken-link annoyance, and a 2023 security report carrying the one-line proof of concept open 'https://$ calc.exe ' closed as not planned, the maintainer quoting the README’s standing disclaimer: “This package does not make any security guarantees. If you pass in untrusted input, it’s up to you to properly sanitize it.” The MCP TypeScript SDK, handed an http/https allowlist proposal in August 2025, closed it without merging and shipped a three-scheme denylist instead. The clients that hold the line do it with argument vectors: gemini-cli, Claude Code, github-mcp-server, and Docker’s mcp-gateway never build a command line out of a remote string. Anomaly’s response, as reported by Pillar: “we’ve updated the dependency, but generally, trying to deal with a malicious MCP server is outside their threat model.” The fix itself was thorough, three layers in 1.18.33. But it shipped as a refactor, presented as consolidating eight browser-launch call sites, with no advisory and no CVE behind it. Pillar reported the flaw privately on August 29, watched the patch merge on September 25 and ship on September 28, and published on October 4 without a CVE. The report’s own disclosure timeline gives that October 4 date; the page’s byline reads October 19. The direction here runs one way: a remote MCP server executing code on the developer’s own machine. For teams running OpenCode on Windows or WSL: - Upgrade to 1.18.33 or later. - If the upgrade waits, remove unvetted remote MCP servers from the OpenCode configuration until it lands. - Verify the open dependency is at 11.0.4 or higher. Scheme validation alone is not sufficient. - Inventory OpenCode installations directly. There is no CVE for scanners or dependency bots to match, so nothing will find them for you. The record here is the inverse of this week’s other trust stories. The patched Palo Alto bypass that Qilin and INC exploited https://forkast.news/qilin-and-inc-exploited-a-patched-palo-alto-vpn-bypass-for-four-months-connectwise-shows-where-the-same-trust-failure-went-next/ for four months was a fix the industry knew about. GitLab’s patch release and its poisoned discovery map https://forkast.news/gitlab-patches-an-auto-linking-account-takeover-and-a-poisoned-discovery-map-both-trusted-input-nobody-checked/ were documented at disclosure. The PHP2Shell pair https://forkast.news/ai-assisted-research-uncovers-critical-php2shell-rce-vulnerabilities/ carried its own advisory. OpenCode’s flaw has a patch, a public report, and no official record tying them together. The discovery layer is where the identity decision gets made: a server that names its own authorization endpoint is making your security decisions for you, the same gap this desk mapped across two theories of agent identity https://forkast.news/two-theories-of-agent-identity-fido-vs-agntcon/ this week. Both theories verify credentials. Neither checks who answers the map.