OpenCode Breach and MCP RCE: What We Hardened Before the Headlines

On August 17, 2026, we published Why Enterprises Restrict Open-Source AI Tools. Our argument was straightforward: an AI coding agent is not merely a chatbot. It is a small execution platform with network connections, OAuth flows, credentials, plugins, tools and child processes. We specifically warned about MCP trust, remote configuration, and the authorization channel created when an agent authenticates to an external service.

On October 17, OpenCode disclosed a breach affecting a reported 1.4% of its hosted Console users. On October 19, Pillar Security published a technical report on an MCP OAuth remote-code-execution flaw affecting Windows and WSL. The two events were different failures, but both involved an overly consequential trust boundary.

The interesting question is not whether we secretly knew about either exploit. We did not, and we are not claiming discovery credit. It is whether our earlier threat model produced concrete safeguards at the boundaries that the incidents later highlighted. The public OpenCode enterprise fork lets anyone inspect the answer.

Two headlines, two different failures

The Console incident involved OpenCode’s hosted account infrastructure, where some users had stored third-party AI-provider API keys. OpenCode attributed the incident to unauthorized access to a legacy system and said affected users were notified. A stolen provider key can be used outside the original application, potentially generating unauthorized charges. This is a credential-custody and cloud trust problem. A local fork cannot fix a provider key already exposed on someone else’s hosted service.

The Pillar Security report described a separate local execution vulnerability. An attacker-controlled remote MCP server could supply OAuth discovery metadata containing an authorization URL. In affected OpenCode builds, that URL reached the browser-opening helper. On Windows and WSL, the pinned open package used PowerShell in a way that could interpret part of the attacker-controlled HTTPS URL as a command.

This did not require prompt injection, a model deciding to run a command, or a downloaded malicious MCP package. The failure occurred while connecting and authenticating. Pillar identified affected OpenCode versions 1.0.137–1.18.32 on Windows/WSL. OpenCode 1.18.33, released September 28, 2026, contains the patch, including [email protected]. Native Linux and macOS did not use that particular PowerShell launch path.

These incidents illustrate why a coding agent’s security cannot be reduced to its model’s behavior.

What we said before the incidents

Our August article already asked questions that should be part of every agent security review:

• Can an untrusted server supply a URL, redirect, or new network destination?
• Can OAuth discovery create a second authorization channel, callback listener, or token store?
• Can project configuration override a managed security policy?
• Can a connected MCP server introduce tools, prompts or instructions without another approval step?
• Are provider credentials kept locally or entrusted to an external control plane?

These were risk-class predictions, not evidence of advance knowledge of the specific October bugs. They led to implementation choices in the fork that can now be evaluated against public incident details.

A source-level review of our hardened fork

1. MCP OAuth is rejected before browser execution

The MCP service rejects startAuth when OPENCODE_ENTERPRISE_MODE is enabled. The authentication and token-completion operations also have enterprise guards.

Importantly, we put another check at the execution sink: the MCP browser service rejects before calling the open package. The OAuth callback module refuses to start or wait for an OAuth callback under enterprise mode.

The managed MCP policy schema explicitly requires oauth.allowed: false.

Result: if enterprise mode is actually enabled and these paths are used, malicious OAuth discovery metadata cannot reach the reported browser-launch sink. This blocks that specific RCE chain. It is not proof that the entire fork is free of command-execution vulnerabilities.

2. A connection does not automatically give the model tools

The current fork separates the managed MCP lifecycle into diagnose, connect and catalog modes. A server must have an admitted managed definition before a connection is made. The policy includes an exact destination URL, denied redirects, DNS constraints, bounded requests and responses, header controls, secret references, and tool allowlists.

The enterprise runtime can initialize a carefully managed remote connection and privately discover a tool catalog without exposing executable MCP tools to the agent. Public enterprise clients() and server instructions remain unavailable. That is a deliberate distinction between observing a remote service and authorizing the model to act through it.

The enterprise HTTP transport also rejects redirects, pins the admitted destination, and constrains traffic. These are useful defenses against SSRF and misrouting, although URL checks alone are not the fix for PowerShell command expansion. Pillar showed that an ordinary HTTPS URL could carry the payload.

3. The hosted Console is not an automatic credential dependency

In enterprise mode, the configuration loader skips account-backed remote configuration, well-known remote configuration, and Console token injection. The public provider-login and account paths also have enterprise checks.

That is a credential-custody decision, not a repair of the Console breach. An enterprise distribution that never gives third-party provider keys to OpenCode Console avoids exposing those keys through that Console storage path. It does not protect keys that were already uploaded or guarantee that all other integrations handle credentials safely.

For users affected by the hosted incident, the practical response is to revoke and rotate keys at the underlying AI provider and inspect usage and billing. Removing a key from a breached application’s interface does not necessarily invalidate a stolen copy.

Where the original engineering judgment matched reality

This table reports what code inspection supports. It is not a newly executed exploit reproduction or certification of a deployed product.

The gaps we still need to fix

Security credibility depends on documenting what did not hold.

First, the fork still pins the affected open dependency. The reviewed packages/opencode/package.json has OpenCode version 1.17.20 and [email protected]. Enterprise mode prevents the published OAuth route, but ordinary mode retains the vulnerable dependency. We need to upgrade to a fixed open release, import the upstream browser-opening defense, and verify the patched behavior on Windows/WSL. Simply adding a URL scheme check is not enough.

Second, enterprise mode is currently an opt-in runtime flag. The flag source reads OPENCODE_ENTERPRISE_MODE from an environment variable and defaults to off. A developer who can run the ordinary build without that flag can avoid its restrictions. A real managed enterprise distribution needs enforcement outside a user-controlled environment toggle, plus OS-level egress and process controls.

Third, shell tools and other process execution paths need their own isolation. A network policy implemented only in application HTTP clients does not automatically prevent arbitrary child processes, Git hooks, plugins or local toolchains from making outbound connections.

None of those limits negates the value of the boundary design. They define the next engineering work.

Three tests that would strengthen the claim

1. Adversarial OAuth simulation: use a local mock MCP server returning an untrusted authorization URL. Assert zero enterprise-mode browser launches, callback listeners, child processes and token writes.
2. Windows and WSL regression: after patching open, use harmless marker-based cases to prove that an authorization URL is passed as data, never interpreted by PowerShell.
3. Managed policy enforcement: demonstrate that a distributable enterprise build cannot be launched with guardrails silently turned off, and independently check OS-level network restrictions.

A passing policy parser or unit test is not the same as verifying the dangerous execution sink. These are proposed tests, not experiments we claim to have run for this article.

What was actually ahead of the curve

The foresight was architectural. Months before these October headlines, our published analysis treated remote metadata, OAuth, process execution, tool authority, and externally held secrets as independent trust boundaries. The public fork implements several direct barriers at those boundaries.

We did not discover Pillar’s exploit or predict the Console intrusion. Pillar deserves credit for its original research, and OpenCode shipped the upstream MCP RCE fix before the October report. Our stronger, verifiable claim is narrower: the controls we argued for before the public headlines directly avoid the specific enterprise-mode OAuth/browser attack path and avoid an optional Console custody path.

The same source review also exposes unfinished work: upgrade the vulnerable dependency and make the enterprise security policy enforceable rather than optional.

That is what useful security foresight looks like: controls that hold up when the incident arrives, backed by code links, with the remaining failure modes plainly stated.

Primary evidence

• RAMGPT: the August 17 enterprise hardening article
• Pillar Security: OpenCode MCP OAuth RCE technical research
• TechCrunch: OpenCode Console breach report
• Public source code: enterprise OpenCode fork
• Upstream OpenCode repair PR #51414