OpenCode is the open-source AI coding agent that has become a favorite inside developer terminals, and one of its quietest features is the most dangerous: every time you run it, it silently starts a local HTTP server on localhost:4096 that exposes a full API and a web interface. Two security advisories published in January 2026 show why that design matters. Together they describe a coding agent that could hand an attacker shell access to your machine without a single keystroke of malware on disk.
The unauthenticated server that hands out shells
The first and most serious finding is catalogued as CVE-2026-22812, a high-severity flaw in how OpenCode stands up that local API. When the CLI starts, its worker spawns the server with no authentication middleware at all. Anything that can reach the port can talk to the API as if it were the user. The server even responds to cross-origin browser requests because it enables permissive CORS with the default Access-Control-Allow-Origin wildcard.
Three endpoints turn that open port into a remote-code-execution primitive:
- POST /session/:id/shell which executes arbitrary shell commands with your privileges, wired up in server.ts.
- POST /pty which spawns interactive terminal sessions, the same machinery the agent uses to run builds.
- GET /file/content?path= which reads any file on the system you can read.
The advisory notes the report was first sent by email to support at sst.dev on 17 November 2025 under the project security policy, and received no response before publication. The impact is broad because the attack arrives from two independent directions.
The first vector is a local process. Any malicious npm package, script, or compromised application running on the same machine can POST to the localhost API and execute shell commands as you. The second vector is nastier and browser-based: a malicious website can exploit visitors who have OpenCode running at that moment. OpenCode confirms the browser drive-by works against Firefox, while newer Chromium builds add a Local Network Access prompt that slows some variants of it down. That set of facts describes a drive-by attack surface for anyone who opens a terminal and then visits an ad-laden page.
There is a checkbox that widens the blast radius further. Run OpenCode with the mdns flag and the server binds to 0.0.0.0 and advertises itself over Bonjour, extending the unauthenticated API to the entire local network instead of just one machine.
The critical chain: XSS to a terminal inside your IDE
The second advisory, CVE-2026-22813, is rated critical because it turns a simple chat response into arbitrary command execution. OpenCode renders model output by dropping HTML directly into the DOM, with no DOMPurify-level sanitization and no Content Security Policy on the web UI. That alone would not be enough for a reliable one-click strike, but the web interface ships an override that makes it exploitable.
In the app package, the web UI reads a url query parameter to decide which server it talks to. An attacker who tricks a victim into opening a crafted localhost link can point that parameter at an attacker-controlled server. A reverse proxy such as mitmproxy can then feed back a forged chat session whose markdown contains a hidden image tag with an onerror handler, which executes JavaScript inside the localhost:4096 origin on load.
Once JavaScript runs on that origin, it is only one fetch call away from the pty API, which spawns processes such as a shell. The public proof of concept demonstrates the full chain: a victim opens a link, and a marker file silently appears in the temporary directory seconds later. Chinese characters or emoji in the payload do not even matter; the exploit encodes its script base64 and hides it inside an image tag.
The OpenCode team mitigated the specific trigger server-side on 9 January 2026 by no longer honoring the url parameter, so the original proof of concept no longer works as written. That does not remove the underlying problem. The advisory is explicit that any future XSS bug in the web UI still hits users who have not upgraded, and the recommended fix is to move to version 1.1.10 or later, which disables the web UI and API entirely to shrink the attack surface.
Shrinking the blast radius on your own machine
Both vulnerabilities share a root cause worth understanding if you write code for a living. A local development server that binds to a known port, grants global CORS, and runs with no authentication is a trust boundary that does not hold against either local malware or a malicious webpage. When that same server also exposes a shell endpoint, the boundary becomes a fully armed remote shell.
For developers running OpenCode today, the practical checklist is short:
- Upgrade to version 1.1.10 or later so the local server and web UI are disabled by default.
- Never run with the mdns flag when you are on a shared or untrusted network.
- Avoid keeping an active coding-agent session open while browsing untrusted websites.
- Review anything that posts to localhost on your machine, especially packages from third parties.
The deeper lesson extends far beyond one agent. Every AI coding tool that spins up a local API with permissive CORS is building the same trap, and the community has begun to notice. As these terminal-based assistants grow more powerful, the boundary between your editor and your operating system is getting dangerously thin, and an unauthenticated localhost shell is the weakest seam we have found yet.
Comments