PaPoo
cover

The annoying part is not the bug — it’s the “not our threat model” shrug

What gets me here is how familiar this feels. A developer tool wires together OAuth, MCP servers, and a browser helper, then quietly crosses the shell boundary on Windows. That’s exactly the kind of place where a “harmless” refactor turns into code execution. I’m less surprised that the bug existed than by the decision to treat it as outside the product’s security boundary after it was reported.

That boundary claim feels a little too convenient. If a tool is explicitly built to connect to third-party MCP servers, then “a malicious or hijacked server can abuse that connection” is not some weird edge case you can hand-wave away. It’s the whole point of the integration surface. Maybe Anomaly is being strict in a product-policy sense, but from a developer’s perspective that’s not very reassuring. If an attacker can get code to run when I click sign-in, I don’t really care whether the path was labeled trusted or untrusted in a design doc.

The lack of a CVE is the other thing that bothers me. Not because every bug deserves a shiny number, but because the practical effect is ugly: scanners miss it, alerts miss it, and teams who rely on inventory tooling get a false sense of safety. That’s especially bad for something that affects a narrow but real slice of users — Windows and WSL — where people may assume they’re fine because they’re not on macOS or Linux. In this case, “routine change” is not a virtue; it just means the dangerous part hid inside normal maintenance.

I also think the article lands on the right historical comparison. This isn’t some novel AI-agent apocalypse story. It’s the same old command-injection class wearing a new outfit: a URL gets handed to a shell, shell metacharacters do their thing, and now your coding assistant has helped an attacker. The fact that a nearly identical bug showed up in mcp-remote last year suggests the ecosystem is still repeating the same mistakes around browser launchers and OAuth plumbing. People keep bolting agent tooling onto existing desktop patterns without really re-auditing the seams.

If I were running OpenCode on Windows or WSL, I’d upgrade immediately, then audit every remote MCP server I’d ever added. Not because the article proves active exploitation — it doesn’t — but because this is exactly the sort of flaw that sits quietly until someone notices a convenient takeover path in the wild.


Reference: OpenCode Flaw Lets Malicious MCP Servers Execute Code During Sign-In on Windows and WSL

同じ著者の記事