opencode fixed a no-consent MCP OAuth RCE in 1.18.33, and no CVE was ever issued

What the bug did

opencode, the open-source coding agent from Anomaly, shipped a fix on September 28 for a vulnerability that let a remote MCP server run PowerShell commands on a user's machine with no further interaction and no consent prompt. According to Pillar Security's write-up, versions 1.0.137 through 1.18.32 were affected on Windows and WSL only; macOS and Linux were not.

The trigger was simply adding a remote MCP server. Once configured, the OAuth sign-in flow started on its own, and that is where execution occurred. No malicious package was installed and no prompt was injected.

The attack chain

Pillar Security describes the path in four steps. During OAuth discovery, the remote MCP server controls the authorization_endpoint string. opencode passed that URL to the open npm package, version 10.1.2, to launch a browser. On Windows, open handed the target to PowerShell, which expands $(...) expressions inside double-quoted strings. And because the URL was a well-formed https address with no spaces, a scheme check did not stop it — the browser launch failed, but the injected expression had already run.

Pillar proposed a CVSS score of 9.8, though that is the researcher's number, not an official one, because no CVE exists to attach it to. Pillar also notes the server did not need to be malicious when configured; a server that turns hostile later reaches the same path.

A fix disguised as a refactor

The fix landed in version 1.18.33 through a pull request titled "refactor(core): share a browser opener across opencode and tui." It was more than a rename: it bumped open to 11.0.4, routed every browser launch through a single helper that accepts only http and https URLs, and added a scheme check where the OAuth URL is handed off.

The release notes describe the change as "MCP browser launch failures are now reported when the launcher exits immediately" — accurate, as a dev.to analysis by Gabriel Anhaia observes, but not phrasing a security team would search for.

Per Pillar's timeline, the report went in privately on August 29. Anomaly replied on September 25, after a follow-up outside the advisory thread, saying it had updated the dependency but that dealing with a malicious MCP server was generally outside its threat model. The fix merged the same day and shipped three days later. A similar bug class in mcp-remote received CVE-2025-6514, rated 9.6, in July 2025 — that project got a CVE, opencode got a refactor.

Why scanners stayed quiet

As the dev.to piece points out, Dependabot only fires on advisories reviewed into the GitHub Advisory Database, so with no advisory there is no alert. There is a second gap: Dependabot scans a repository's default branch, while agent CLIs installed with curl, Homebrew or npm -g on a laptop usually sit outside any repository's dependency graph entirely.

Nor is opencode an outlier. Adversa AI's catalog of ten documented attacks involving Claude Code, published September 23, counted only two that produced CVEs. In Adversa's summary, a vulnerability scanner sees two of ten working attacks and an SBOM sees none — and Adversa is careful to note that none of this reflects bad faith by vendors.

Treat agent CLIs like browsers

The dev.to author's broader argument is that coding agents process untrusted content all day — web pages, issues, READMEs, MCP servers, other people's repositories — exactly like browsers, so they should be updated like browsers: automatically, without waiting for a CVE.

Current behavior is inconsistent. Claude Code native installs update in the background, but Homebrew, WinGet, apt, dnf and apk installs do not by default. opencode checks for new versions and shows a notice, but never installs automatically; users must run /update in the TUI or opencode upgrade.

The proposed model has three parts: updates on by default through a stable channel, an enforced version floor — Claude Code's requiredMinimumVersion managed setting can refuse to start on an older version — and an inventory of installed agents that the team maintains itself, since Pillar's advice for finding exposed opencode installs is blunt: inventory it directly.

Why it matters

The security tooling most teams rely on assumes vulnerabilities get CVEs and live inside a repository's dependency graph. Agent CLIs break both assumptions: fixes ship without advisories, and the binaries live on developer machines outside any repo scan. Until tooling catches up, a fully vulnerable opencode 1.18.32 install will read as clean, and the only reliable defenses are enforced version floors and manual inventory of what agents your team actually runs.