Brief · Builders
Fixed in September. Your scanner still doesn't know.
In a report dated Oct 19, Pillar Security showed that opencode, on Windows and WSL, could run an attacker's code just because you connected to a remote MCP server. No prompt injection. No click.
Here's how it worked. During the automatic OAuth handshake, opencode took the MCP server's authorization_endpoint and handed it to the open package. On Windows, open@10.x routes that through PowerShell without escaping. So a server that advertises https://evil.test/$(...) gets its $(...) executed on your machine. macOS and Linux aren't affected.
Affected: opencode-ai 1.0.137 through 1.18.32, on Windows or WSL, with remote MCP servers configured. Pillar proposes a CVSS of 9.8, and puts opencode at about 3 million weekly npm downloads and 211K GitHub stars. Those are Pillar's numbers. There's no CVE and no advisory. Per Pillar, the maintainers consider malicious MCP servers outside their threat model, and the fix shipped as a refactor in 1.18.33, published to npm on Sep 28. No in-the-wild exploitation has been reported.
CVE-based scanners and dependency alerts key on CVEs. This one doesn't have one, so they won't flag it. Your own version inventory still can.
(Not to be confused with the separate OpenCode Console key breach, which we covered here.)
Sidebar: the plumbing is the target
Two more agent servers shipped with "everyone, everything" defaults:
- Google's Agent Mesh (SAM), CVE-2026-103091. Anyone with a valid token from the configured identity provider can self-register. The default policy then grants wildcard access to every MCP tool on every node. Per the GHSA, a one-hour token buys a 90-day mesh credential. Fixed in v0.1.0-alpha.9. The README says it's "not an officially supported Google product."
- Cognition, CVE-2026-109437. Per VulnCheck, there's no API auth, and the default sandbox is a local shell. Fixed in 0.13.0.
No exploitation has been reported for either. The pattern: the connections between agents (OAuth handshakes, enrollment endpoints, session APIs) are now where the bugs live.
My take: "out of our threat model" is a fine sentence for a design doc and a terrible one for a release note. If the fix matters enough to ship, it matters enough to tell people.
What to do:
- Check versions by hand on every Windows and WSL machine that runs opencode. If you installed it through npm,
npm ls -g opencode-aishows the version. Anything from 1.0.137 to 1.18.32 needsnpm install -g opencode-ai@latestto get 1.18.33 or later. - Check your opencode configs for remote MCP servers, and remove any you haven't vetted. Vet them like a stranger's shell script.
- If you find an affected version with remote servers configured:
- Preserve the endpoint's logs before you upgrade.
- If you have PowerShell script-block logging, check Event 4104 around the time MCP sign-in ran. Every
open@10launch is encoded, so look at the decoded command for$(inside theStarttarget. On WSL,powershell.exeruns on the Windows host, so the parent chain may not show opencode. - Rotate the credentials on that machine that opencode could reach.
- Builders: launch URLs with argv-style calls, not a shell, and bind OAuth discovery to the server's configured origin. Per Pillar, a scheme allowlist alone doesn't stop this payload.
- SAM and Cognition users: upgrade. On SAM, restrict who can enroll, and reissue mesh credentials.