Researchers at Pillar Security say the makers of OpenCode, an open-source agentic AI coding tool, quietly patched a critical remote code execution flaw without issuing a CVE or a security advisory. Because no identifier exists, vulnerability scanners and dependency alerts will not flag vulnerable installations.
Malicious MCP Servers Can Run Code During OAuth Authentication
Pillar Security researcher Eilon Cohen disclosed the vulnerability in a report published on Monday. An attacker-controlled remote MCP server can execute arbitrary code on a developer’s machine during MCP OAuth authentication. The attack requires no extra user interaction or consent.
OpenCode has more than 218,000 GitHub stars. The vulnerable versions run from 1.0.137 to 1.18.32 on Windows and WSL. Developers in that range who connect to untrusted MCP servers risk code execution on their own machines.
Affected Versions and the Fixed Release
Anomaly, OpenCode’s maker, fixed the flaw in version 1.18.33. Users should upgrade to 1.18.33 or later.
Disclosure Timeline: From Private Report to Silent Fix
The disclosure unfolded over roughly seven weeks, from a private report at the end of August to Pillar’s public write-up on October 19.
Pillar’s Report and Anomaly’s Response
Pillar reported the flaw privately through a GitHub Security Advisory at the end of August. About a month later, Anomaly acknowledged receiving the report but said malicious MCP servers are “outside their threat model.”
The September 28 Patch Without an Advisory
Anomaly patched the flaw on September 28 in version 1.18.33. It issued neither a CVE nor a security advisory. Pillar published its report on October 19, roughly three weeks after the fix.
Why a Missing CVE Matters to Defenders
Vulnerability management tools generally work from published identifiers. Without a CVE or advisory for the OpenCode flaw, a scanner has nothing to match against, and a dependency alert will not tell a developer that the installed version is vulnerable. The only signal is Pillar’s public report, which means developers learn of the risk only if they read it.
The dispute between Pillar and Anomaly rests on a disagreement about scope. Pillar treats a malicious MCP server as a legitimate attack vector that can lead to code execution on the developer’s machine. Anomaly told the researchers that such servers fall outside its threat model, though it fixed the issue in the following weeks.
Scope: Windows and WSL Only
The affected range covers Windows and WSL. The material reported does not describe the flaw affecting other platforms.
The timeline highlights the gap between a fix and its disclosure. Pillar’s report reached Anomaly at the end of August, and the fix landed on September 28. Pillar’s public report came on October 19. In the weeks between the fix and the report, anyone running an affected version had no advisory telling them to upgrade.
Pillar’s account of the exploit centers on the authentication step. When a developer connects OpenCode to a remote MCP server that uses OAuth, a malicious server can use that exchange to run arbitrary code on the developer’s machine, with no extra prompt or consent. That makes the connection itself, rather than any later action by the user, the point of compromise.
Related OpenCode Issue Is Separate
This vulnerability is distinct from an OpenCode Console API-key exposure reported earlier in the week. That earlier issue involved a different component and is not connected to the MCP OAuth flaw.
The reporting leaves several questions unanswered, including how many developers connect OpenCode to third-party MCP servers and whether any attacker has used the flaw. What it does establish is the sequence: private report, acknowledgment with a threat-model objection, a quiet fix, and a public disclosure after the fix was already available. Users running anything between 1.0.137 and 1.18.32 on Windows or WSL are in the affected range, and the recommended step is to move to 1.18.33 or later.
Agentic coding tools connect to external MCP servers to extend what they can do, and each connection extends the trust the developer’s machine places in a remote party. In this case, that trust extended as far as code execution during the authentication step itself. Developers who ran versions in the affected range and connected to MCP servers they did not control have no scanner-driven way to learn whether they were exposed, which leaves the version number as the sole indicator.
