AIDEFEND in Action AIA-0111 Validated Research Published: Oct 26, 2026

OpenCode: An MCP OAuth URL Reaches the Windows Shell

Pillar Security demonstrated code execution in OpenCode, an AI coding agent, during remote MCP OAuth authentication on Windows and WSL. A server-controlled HTTPS authorization URL reached an unsafe browser-launch command and was interpreted by PowerShell. The model did not need to follow a prompt. OpenCode 1.18.33 fixed the affected launch dependency; the disclosure reports no CVE assignment.

Remote Code ExecutionClient SecuritySupply Chain DefenseAI Coding AgentMCP Security
2 applicable AIDEFEND defenses
Source: Open and Shut: Remote Code Execution in opencode via MCP OAuth 
Author: Eilon Cohen
Original article: Oct 19, 2026

Threat Analysis

  • The server response crosses into a shell: OAuth supplies a URL, the client launches a browser, and an unsafe helper allows PowerShell to interpret attacker text. It bypasses the need to influence the model altogether.
  • Scheme checks are not argument safety: a URL can be valid HTTPS and still carry shell syntax. Trusting the configured server also misses later compromise of the same endpoint.
  • Fix the actual client population: the researcher documents a fixed release without a CVE. Fleet inventory and installed dependency verification matter more than waiting for a conventional vulnerability-feed alert.

Applicable AIDEFEND Defenses (2)

AID-H-003.010
Deployed AI Software Vulnerability Remediation Lifecycle
Very High
Inventory every Windows/WSL OpenCode installation directly and replace affected versions with 1.18.33 or a later supported fixed build. Verify the actual launch dependency and process used by installed clients, including portable and embedded copies. Test a harmless shell-metacharacter URL through the full OAuth/browser handoff in isolation and require zero unintended command effects. A CVE-only scanner cannot establish coverage when the flaw has no CVE.
AID-H-028.004
Client Response Parsing, Rendering & Execution Surface Hardening
Medium
The client developer can require trusted, one-time confirmation of the full normalized OAuth destination before any browser/helper invocation or prefetch. Apply the no-implicit-opening rule to this native OAuth launch path, not only MCP URL elicitation; the guidance example needs that client adapter. This blocks an unapproved trigger and provides origin restrictions, but a user-approved HTTPS URL can still contain shell syntax. The launcher patch remains necessary; consent does not sanitize PowerShell input.

What Defenders Should Do Now

  • Upgrade Windows/WSL OpenCode to the supported fixed release and verify all installed copies, not just the package used in CI.
  • Disable unneeded remote MCP connections until the client is verified. A managed confirmation broker can stop unreviewed navigation but cannot sanitize an approved malicious URL.
  • Test the OAuth handoff with harmless fixtures in an isolated machine and observe child processes. Do not treat HTTPS validation or a WSL sandbox as evidence that the Windows launch path is safe.

Conclusion

AIDEFEND  maps the decisive protection to deployed-software remediation, with explicit confirmation as a limited additional control. The client must keep server-returned URLs out of shell interpretation; model guardrails cannot repair a launch helper that executes before the model acts.

Last updated: