OpenCode's MCP login crossed into PowerShell: why the HTTPS check was not the fix

The evidence, and its limits

The research published by Pillar Security provides the end-to-end code trace and a proof of concept. The OpenCode pull request merged on 25 September independently confirms three patch elements: a new shared browser opener, HTTP/HTTPS scheme checks at the opener and OAuth redirect boundary, and an upgrade of the open dependency from 10.1.2 to 11.0.4. The upstream open package warns that callers must handle untrusted input. Its PowerShell escaping change predates this disclosure.

That evidence establishes a vulnerable source-to-sink path and the patch. It does not establish that a public attacker exploited it, that a particular developer's machine was compromised, or that the separate October OpenCode Console credential incident resulted from this flaw. The two stories involve different systems and require different checks.

A normal login becomes a host command

OpenCode's MCP documentation says a remote server can be configured by URL. If it requires authentication, OpenCode handles OAuth automatically or through opencode mcp auth SERVER_NAME. In the normal flow, a 401 response leads the client to discovery metadata, which names an authorization_endpoint. Opening that endpoint in a browser is expected behaviour. The dangerous assumption was treating the discovered URL as safe material for a platform-specific launcher merely because it was intended for a browser.

Pillar traces the affected route through the MCP SDK, OpenCode's OAuth provider and browser service, then into open@10.1.2. On Windows and WSL, that dependency built an encoded PowerShell command. Its application name was escaped, but the target URL was placed inside a double-quoted string without the corresponding protection. PowerShell interprets subexpressions inside such strings before the browser-launch command completes. Pillar says its test executed even when opening the browser subsequently failed. This is command injection in the client-side protocol plumbing; a model response or tool invocation is not required.

The source of the hostile string is important. A remote MCP service that was safe when first configured could later be compromised or have its domain reassigned. The researcher also describes a malicious service deliberately configured by a user. The published record does not quantify either population. Merely having OpenCode installed is not evidence of a compromise; the relevant exposure requires an affected build, a Windows/WSL launch path, and a remote MCP OAuth response controlled by an attacker.

Follow the boundary, not the brand name

The diagram below follows the code path described by Pillar and marks the precise transition from remote data to a host shell. It is a source-to-sink model, not a record of an observed intrusion.

Why the visible URL guard was insufficient

The patch is easy to misread. Pull request #51414 adds a helper that parses a URL and only accepts http: or https:. It also checks the scheme in redirectToAuthorization. Those are useful controls against non-web schemes. They do not stop Pillar's example, because the example begins with https://. The dangerous content is in the URL string that the older launcher embeds in a PowerShell double-quoted command, not in an exotic protocol prefix.

Pillar identifies the change that blocks its demonstrated route as the upgrade to open@11.0.4: the newer dependency protects the target in the Windows PowerShell command. The upstream escaping commit supports the version-level explanation. A scheme allowlist, input validation and safe process invocation solve different problems. For software authors, the strongest design is to pass a URL as a process argument where the platform permits it and avoid reconstructing a shell command from remote metadata. If a shell cannot be avoided, exact shell-specific quoting and regression tests become critical.

This matters beyond OpenCode. Pillar links earlier Windows MCP client cases to CVE-2025-6514, CVE-2025-58062 and CVE-2025-10619. Those identifiers belong to other products. They should not be entered into an OpenCode asset record as though they describe this patch. The common engineering problem is a remote authorisation field reaching a local process launcher; the affected versions and fixes differ by client.

Which machines belong in the inventory?

Pillar gives OpenCode 1.0.137 through 1.18.32 inclusive as the affected range on Windows and WSL. Its reported fixed version is 1.18.33, released on 28 September 2026. The public pull request records the dependency move and boundary checks, while OpenCode's release list provides a release trail. Check the actual version running on each developer host with opencode --version; then inspect remote MCP configuration and authentication status with opencode mcp list. OpenCode's documentation also describes opencode mcp auth list and opencode mcp debug SERVER_NAME for diagnosis. Do not run an authentication or debug flow against an untrusted server merely to test the bug: that can initiate the very metadata exchange at issue.

The inventory question is narrower than “does this company use AI?” or “does it use MCP?”. It is: which Windows or WSL endpoints ran the affected OpenCode interval and connected to a remote MCP server that could initiate OAuth? Project-level and user-level configuration both matter. A remote MCP definition can be enabled for a project even when the organisation's central list looks clean. Conversely, a local MCP command or a macOS/Linux browser-opener path is not this demonstrated Windows/WSL route. Pillar's cross-platform conclusion is about this proof of concept, not a blanket guarantee that the other platforms or clients have no MCP security issues.

For a fleet, record the host OS, whether WSL is used, OpenCode binary version, installation method, configured remote servers, their current owners, and the date of last connection. The known version interval is a practical query because no OpenCode CVE currently supplies a vulnerability-management match. A newer installed binary should be verified on the actual execution path: parallel package-manager and standalone installations can leave an older opencode first on a user's PATH.

Four dates, two unresolved publication labels

Pillar's disclosure timeline says it reported the issue privately on 29 August 2026, OpenCode merged the fix on 25 September, and version 1.18.33 was released on 28 September. The same timeline says Pillar published its report on 4 October. Its page header, however, shows 19 October 2026. Those two publication labels conflict. The merge and release dates are separately supported by the public code and release trail; the precise first public date for Pillar's text should remain qualified until the page history is reconciled.

The researcher says Anomaly treated malicious MCP servers as outside its threat model and shipped the change as a refactor, without a security advisory or CVE. The pull request's title and summary do indeed present a browser-opener refactor and tests, not a security notice. Pillar's proposed 9.8 CVSS v3.1 rating is the researcher's assessment, not an official OpenCode CVE score. A missing CVE does not make an affected version safe, but the public record also does not establish widespread exploitation.

The control decision is different for users and maintainers

For developers on Windows or WSL: check opencode --version on the machine and in the shell where you actually launch it. Upgrade a build in the 1.0.137–1.18.32 interval to 1.18.33 or later. Review remote MCP entries, especially services whose ownership or domain has changed. If an upgrade is delayed, disable or remove unvetted remote MCP servers; the OpenCode MCP configuration guide documents the enabled setting and OAuth controls. Preserve a copy of the configuration for a security review before changing it where your organisation requires that.

For security teams: prioritise machines with the affected build and remote MCP OAuth, then examine process telemetry around connection and sign-in times. A relevant investigative lead would be an unusual PowerShell child process of the OpenCode/browser-opener chain, especially one using an encoded command, followed by file, network or credential-access activity. That is a hypothesis for log review, not a published indicator of compromise or proof that every PowerShell launch is malicious. If logs are absent, state the visibility limit rather than declaring the host clean.

For MCP client maintainers: trace every remotely supplied discovery field to its final consumer on each supported OS. Test URL values that remain syntactically valid HTTPS, not only rejected schemes. Separate “which destinations may be opened?” from “can the value be evaluated by the launch mechanism?”. Ensure unit tests exercise the Windows/WSL path, not only a mocked browser wrapper. A code review that sees an HTTPS allowlist but does not inspect the spawned command can miss the failure mode Pillar demonstrated.

What remains unknown

The public material checked on 20 October gives no count of exposed hosts, evidence of an exploitation campaign, or victim list. It does not establish whether any specific configured service was malicious at connection time. The report explains exploitability under stated conditions; it does not establish a completed intrusion at a particular organisation. An incident claim would need endpoint telemetry, the MCP discovery response received, installed version, platform, and subsequent host activity.

The distinction with the OpenCode Console incident remains operationally important. The Console story concerns potentially exposed provider keys in a hosted service and calls for provider-side key revocation where applicable. This MCP story concerns a local Windows/WSL client parsing a remote authorisation endpoint and calls for client upgrade, configuration inventory and possible endpoint investigation. One does not prove the other.

Sources checked 20 October 2026: Pillar Security technical report; OpenCode fix pull request #51414; upstream open v10.1.2; upstream escaping fix; OpenCode MCP documentation; OpenCode releases. The npm release page returned an access block during this check; the researcher and GitHub release trail were used for the release date.