A 9.8 With No CVE: OpenCode Ran a Hostile MCP Server's Sign-In Link Through PowerShell. The Version Checks Said Allow, Ours Included.
If you run OpenCode on Windows or under WSL, upgrade it to 1.18.33 or later today, and remove any remote MCP server you have not vetted. Versions 1.0.137 through 1.18.32 let a malicious MCP server run a command on your machine during the sign-in step. The fix shipped on September 28, but it shipped as a refactor with no CVE and no security advisory, so a scanner that works from advisories will not tell you to take it. That includes ours. We checked.
What Pillar Security found
Eilon Cohen at Pillar Security found this and reported it privately to Anomaly, the company behind OpenCode, on August 29. OpenCode is an open-source AI coding agent. Its npm package, opencode-ai, was downloaded 11,639,646 times between September 19 and October 18, according to npm's own download counter.
When OpenCode connects to a remote MCP server that wants authorization, it runs an OAuth discovery handshake. Part of the server's answer is its authorization_endpoint, the address of the login page. OpenCode took that address and handed it, unchecked, to the popular npm package open (version 10.1.2) to launch a browser. On macOS and Linux, open launches the browser without passing the address through a shell. On Windows, and under WSL, it built a PowerShell command around the address without escaping it.
PowerShell expands $( ) inside a double-quoted string. So a server could hand back an ordinary-looking https address with a command tucked inside, and PowerShell would run that command as the developer, even though the browser launch then failed. Because the address is a normal https URL, a check that only allows http and https would not have stopped it. Pillar says the real fix was moving to open 11, which escapes the address.
Pillar proposes a CVSS score of 9.8 and calls that its own proposal. Nobody has reported exploitation in the wild, and Pillar published no indicators of compromise, so there is nothing for us to add to our feed.
What triggers it
The two write-ups describe the trigger a little differently. The Hacker News, reporting on October 22, says it fires when the developer runs opencode mcp auth or makes the equivalent request, and that merely configuring a server does not trigger it. Pillar describes the OAuth handshake as automatic once OpenCode connects to a server that asks for authorization. Either way, the attacker needs to control a remote MCP server you have added. Pillar also points out that the server did not need to be malicious on the day you added it. A server taken over later, or a domain that changes hands, works just as well.
The fix that nothing announces
Anomaly merged the fix in pull request 51414 and published 1.18.33 to npm on September 28. Per Pillar and The Hacker News, neither the pull request nor the release notes mention a security flaw, and the vendor did not request a CVE. Pillar quotes Anomaly as saying a malicious MCP server is outside its threat model. Pillar's write-up is dated October 19; its own timeline lists a first publication on October 4.
This is not a vendor that never publishes advisories. OSV, the open vulnerability database, lists two other OpenCode advisories today, GHSA-vxw4-wv6m-9hhh (an unauthenticated local HTTP server that allowed command execution) and GHSA-c83v-7274-4vgp (cross-site scripting in the web UI). This one just was not treated as a vulnerability.
The open package's Windows escaping problem is older still. It was reported in 2023 as sindresorhus/open issue 323 and fixed in open 11. OpenCode stayed on 10.1.2.
What our own checks said, run today
We run two of the tools a careful developer would reach for before installing an agent or connecting it to a server. Here is what they returned.
Jeevesus check-package. Asked earlier today about npm package opencode-ai at 1.18.32, the vulnerable version, it returned verdict allow with known_vulnerabilities 0. The same for 1.18.33, and for open at 10.1.2. We then queried OSV directly: zero records for all three. Every one of those answers is correct by its own rules. check-package looks for known-malicious packages and for published vulnerabilities in the exact version. There is no published vulnerability. A version-scoped lookup cannot match a record that does not exist, and that is true of every scanner built the same way, ours included.
Dredd check_mcp_server. Asked about "opencode", Dredd returned REVIEW, severity unknown, known_to_us false, and suggested io.github.doc2mcp/opencode with the note "Judged as typed." That is also correct, and it is not a verdict on this bug. Dredd judges MCP servers, and OpenCode is the client. Its vulnerability lookup matches published CVEs to registry servers, and there is no CVE here to match.
One small thing from that answer is worth noting. On September 29 we wrote that Dredd had matched the bare name "github" to somebody else's server and returned ALLOW, and that an ambiguous name should come back ambiguous. Today a bare name came back REVIEW, judged as typed, with a did-you-mean. That is the behavior we said we owed.
Where the protection actually is
The useful check here is not on OpenCode at all. It is on the server you are about to sign in to. A malicious MCP server built for this bug would most likely be new, and Dredd returns REVIEW for a server it holds no record of. REVIEW means do not proceed blindly. It is the point where a person looks at the server before the irreversible step, and signing in to it is that step.
So, in order:
1. Upgrade OpenCode to 1.18.33 or later. Check with opencode --version on every Windows and WSL machine. A dependency scanner that works from advisories is unlikely to flag the old one.
2. List your servers. Run opencode mcp list and remove any remote server you have not vetted, especially until the upgrade is done.
3. Do not start an OAuth sign-in against a server you have not checked. Run Dredd on the server first. An unknown server is a reason to stop and look, not a pass.
4. If you build on the open package, do not pass strings from a remote party to it, and move to open 11 or later.
What we are working toward is a way to carry a risk signal that has no advisory behind it, such as a named researcher's write-up with affected versions. That is an intention, not a shipped feature, and we will say so when it ships.
Same door, third time
This is at least the third time we know of that the MCP sign-in step has turned a hostile server's answer into something the client trusted or ran.
In July 2025, JFrog found CVE-2025-6514 in mcp-remote, a proxy that connects local clients to remote MCP servers. A malicious server could embed a command during the connection and authorization phase and have it run on the host. That one got a CVE, rated 9.6, and was fixed in mcp-remote 0.1.16.
On September 29 we wrote about GHSA-qx49-fqc8-xw99 in the official MCP Python SDK, found by Yuval Elbar at Cycode, where a server could name its own login service and the SDK believed it: A Malicious MCP Server Could Name Its Own Login Service, and the Official Python SDK Believed It.
Now OpenCode. Three different bugs, one shape: during sign-in, the server gets to hand the client a string, and the client either executes it or trusts it. Anyone writing an MCP client should treat every field in that handshake as hostile input.
Pillar has been here before too. In October we covered its Grafana MCP server findings, and the blind spot they exposed in Dredd, which then had no CVE lookup at all: The Caller Brings Nothing. Your Agent's Credential Does the Work. We fixed that one. Today's gap is the one that a CVE lookup cannot fix, because there is no CVE. We hit the same wall with Metabase: Metabase Shipped a CVSS 10.0 With No CVE.
And OpenCode was one of the ten agents out of eleven that Adversa's GuardFall research fooled with old shell tricks in July: Ten of Eleven AI Coding Agents Fell to a Shell Trick Older Than the People Who Wrote Them. Coding agents run commands for a living. Every string that reaches a shell needs to be treated that way.
Credit, and what we did not do
The research is Pillar Security's, by Eilon Cohen: Open and Shut: Remote Code Execution in OpenCode via MCP OAuth. The Hacker News reported it on October 22. We did not find this bug, we did not see it first, and we have no telemetry of it being used. Our contribution is the check of our own tools, and the honest answer that they said allow.
We counted 39 checkable claims in this post before publishing and corrected 8 that overstated what a source said or what we can know, among them the trigger, the disclosure date, what Dredd's REVIEW proves, and three sentences that said every scanner or no scanner when we had only checked some. At least 5% of what remains is still wrong, and we do not know which.
If you want to put Dredd and check-package in front of your own agents, the getting-started guide is here: The Membrane, getting started.
If this was useful, or was not, rate it at the bottom of the page.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. If the box below does not load, the same question lives at https://analytics.dugganusa.com/nps.html?post=a-9-8-with-no-cve-opencode-ran-a-hostile-mcp-server-s-sign-in-link-through-powershell-the-version
Comments