No CVE, No Advisory, No Scanner Alert: OpenCode’s Silent Fix for an MCP OAuth RCE

2026-10-21 Agent & Supply Chain Security by al-ice.ai Editorial

On 19 October 2026, Eilon Cohen, head of security research at Pillar Security, disclosed a critical remote code execution flaw in OpenCode, the open-source agentic coding tool with over 218,000 GitHub stars: an attacker-controlled remote MCP server could execute arbitrary code on a developer’s machine during the MCP OAuth authentication handshake, with no additional user interaction or consent. Every version from 1.0.137 through 1.18.32 is affected, on Windows and Windows Subsystem for Linux. The researchers assess it at CVSS 9.8. And here is the part that should concern every enterprise running AI coding agents: the vendor patched it on 28 September in version 1.18.33 without a CVE, without a security advisory, and without a single security-related word in the release notes. Conventional scanners and dependency alerts will not flag the vulnerable installs sitting on your developers’ machines right now.

This is our second OpenCode briefing in as many days and it is deliberately not the same story. Our earlier briefing covered the Console breach — a legacy key-proxy system leaking stored provider credentials, a distillation-style attack against hosted API keys. Pillar’s Cohen told Infosecurity Magazine explicitly that the two incidents are unrelated: the breach hit a hosted system and exposed keys users had stored there, while this vulnerability runs the other way — a malicious remote MCP server executing code on the developer’s own machine during the OAuth handshake. Different target, different attacker position. But as Cohen put it, both reduce to the same question: who you let hand credentials and inputs to an AI coding tool, and what that tool does with them.

The attack: your agent’s OAuth flow is the payload’s front door

The shape of this flaw is what makes it an agent-security story rather than a generic command-injection writeup. MCP servers are, by design, untrusted third-party code descriptions that an agent fetches, reads and acts on — the same trust posture as a web page your browser renders, except the consumer is a process with shell access to your workstation. During MCP OAuth authentication, OpenCode passed a URL through to the operating system’s open routine. On Windows, the vulnerable dependency handed that URL to PowerShell without proper escaping, letting the shell interpret part of the URL as a command. The attacker’s lever is therefore not a buffer overflow or a deserialisation gadget: it is a URL the victim’s own agent willingly opens, served by a remote MCP server the developer chose to connect to — or was tricked into connecting to, which in the MCP ecosystem, with its registries, awesome-lists and one-click install commands, is barely a barrier at all.

Pillar’s researchers stress that the obvious fix does not work. OpenCode’s 1.18.33 patch added URL scheme checks, but scheme validation alone cannot stop this class: the malicious payload can be embedded inside a seemingly legitimate https:// URL, so the check passes and PowerShell still receives a string it parses as code. The fix that actually closes it, per the researchers, was updating the dependency to a version that quotes the URL correctly before handing it to the shell — plus the structural recommendation that matters most: never pass untrusted URLs through shell commands at all, and use argument-based process execution instead so there is no shell interpretation step to abuse. That guidance generalises well beyond OpenCode. Every agent harness that shells out to open a browser, deep-link an IDE, or invoke a helper with a server-supplied URL carries the same primitive until proven otherwise, and the 253 MCP tool bugs catalogued in recent agent research suggest the proving has barely started.

A month to acknowledge, a silent patch, and a threat-model shrug

The disclosure timeline deserves as much attention as the bug. Pillar reported the vulnerability privately at the end of August 2026 through a GitHub Security Advisory with full reproduction material. A month later, the vendor — identified by Infosecurity Magazine as Anomaly — confirmed receipt but said that malicious MCP servers are “outside their threat model.” The patch then shipped quietly on 28 September with no CVE request and no advisory.

That threat-model position is worth examining rather than merely quoting, because it is load-bearing for the whole MCP ecosystem. A remote MCP server is not an exotic edge case: connecting an agent to third-party servers is the product’s core workflow, and registries of community servers are how most developers discover them. Declaring the malicious-server case out of scope is roughly equivalent to a browser vendor declaring malicious websites out of scope — it may be an honest statement of where the team invested, but it leaves every downstream user holding a risk the vendor has decided not to price. Pillar’s publication, three weeks after the silent patch, is the only reason anyone outside the two parties knows to upgrade. Enterprises that gate patching on CVE feeds or scanner findings — which is to say, most enterprises — have had no signal at all.

We verified the silence first-hand rather than taking the researchers’ word for it. The v1.18.33 tag in the sst/opencode repository is timestamped 28 September 2026 (predecessor v1.18.32 on 21 September), and the 1.18.33 release notes are 849 characters of routine bugfixes — Cloudflare AI Gateway timeouts, an MCP browser-launch error message, credential redaction in debug output, Gemini defaults — plus contributor thanks. The words security, CVE, RCE and vulnerability do not appear once. An inventory tool diffing installed versions against that changelog would file it under “routine,” which is exactly the failure mode Pillar warned about.

What to do

Upgrade OpenCode past 1.18.32 now — do not wait for a scanner to tell you. No CVE means no feed entry, no Dependabot alert, no scanner finding. Query installed versions directly (opencode --version across managed hosts, or your MDM’s software inventory) and treat anything at or below 1.18.32 as vulnerable on Windows and WSL.
Audit which remote MCP servers your developers have configured. This flaw triggers during the OAuth handshake with a remote server, so the exposure set is every machine with a remote MCP entry — sanctioned or not. Dump mcp configurations from managed machines and review anything not on an approved list; the malicious-server case being “out of threat model” means you cannot rely on the client to save you.
Treat the Console breach and this RCE as one inventory exercise. They are different bugs, but the remediation audience is identical: teams running OpenCode with stored provider keys and remote MCP servers. Combine the key-rotation sweep from our Console-breach briefing with this client upgrade.
Apply Pillar’s structural fix to your own agent tooling: no untrusted URLs through shell interpreters, argument-vector process execution everywhere, and quote-at-the-boundary as a backstop rather than a strategy. Then check your other agent harnesses — IDE extensions, CLI wrappers, desktop agents — for the same open-URL pattern.
Reconsider patch-gating on CVE presence for AI developer tooling. This is now at least the second near-miss establishing that agent-ecosystem vendors ship security fixes as routine releases. For this software class, track upstream releases directly or vendor advisories, not CVE feeds alone.

Our verification was read-only and external. The affected version range (1.0.137–1.18.32), the Windows/WSL scope, the MCP-OAuth attack position, the August private report, the “outside their threat model” response, the 28 September patch date, the absence of CVE and advisory, the CVSS 9.8 assessment, the scheme-validation insufficiency, the quoting fix, the unrelatedness of the Console breach and the Cohen quote were read from Infosecurity Magazine’s 20 October 2026 report (Kevin Poireault) on Pillar Security’s 19 October disclosure and are attributed to those parties throughout. The v1.18.33 and v1.18.32 tags, their 28 and 21 September timestamps, and the full text of the 1.18.33 release notes — including the confirmed absence of any security mention — were read first-hand from the public sst/opencode repository via the GitHub REST API. No MCP server was connected to, no payload was reproduced, and no vendor or third-party system was probed. Brave Search was used for discovery only.

Sources: