OpenCode is an open-source AI coding agent. Like other agentic developer tools, it needs local powers to be useful: read files, create terminals, run shell commands, and connect the user interface to the agent runtime. CVE-2026-22812 showed how quickly that convenience can become a command-execution service if the local control plane is not treated like a security boundary.

On January 12, 2026, GitHub published an advisory for OpenCode versions before 1.0.216. The problem was blunt: OpenCode automatically started an HTTP server with no authentication. The server exposed critical endpoints for shell execution, interactive terminal creation, and arbitrary file reads. It also used permissive CORS, which allowed browser-based exploitation in some conditions.

The advisory scored the bug 8.8 high. NVD recorded the same issue as CVE-2026-22812 and listed the relevant weakness classes: missing authentication for a critical function, exposed dangerous method or function, and permissive cross-domain policy with untrusted domains.

This was not a subtle model failure. It was a classic web-security mistake wrapped around an AI coding agent.

The Local Server Problem

OpenCode's server was meant to support the tool's own runtime. The advisory identified endpoints such as POST /session/:id/shell for command execution, POST /pty for interactive terminal sessions, and GET /file/content?path= for reading files. Those are not harmless metadata routes. They are the core capabilities an attacker wants on a developer machine.

The server started automatically when OpenCode started. According to the advisory, it listened on default port 4096 or above. No authentication middleware protected the endpoints. Any local process could talk to it. With permissive CORS, a malicious website could also attempt to talk to it from the browser of a user who had OpenCode running.

The proof of concept was not complicated. Create a session, call the shell endpoint, and write the output of a command to a file. For browser-based exploitation, JavaScript on a malicious page could send fetch requests to the loopback interface and ask the OpenCode server to run a command. The advisory noted that this was confirmed in Firefox; newer Chrome versions may prompt for local network access, but the issue still existed in the server design.

The fix landed in OpenCode 1.0.216. The vulnerable range was every version before that.

Why AI Agents Make This Worse

Developers have been shipping unsafe local admin servers for years. The AI-agent version raises the stakes because the server is attached to a tool whose purpose is to manipulate source code and execute commands. When the helper server is unauthenticated, the agent's own privilege becomes the attacker's privilege.

A regular desktop app with a local unauthenticated endpoint might expose application settings. An AI coding agent endpoint can expose the working directory, secrets, SSH material, source files, build outputs, package tokens, and shell access. The whole reason the agent is powerful is the whole reason the vulnerability is dangerous.

That is why "loopback only" is not enough. Loopback access is not a trust boundary. Malware on the same machine can call it. A malicious dependency installed by a different project can call it. A browser can sometimes call it, depending on network-access restrictions and CORS behavior. The advisory also warned that OpenCode's --mdns flag could bind the server to all interfaces and advertise it on the local network, extending the exposure beyond the machine.

In other words, the tool created a command plane, put it on HTTP, and forgot to prove who was using it.

The Vibe Coding Angle

Vibe coding encourages developers to keep an AI agent running while they browse documentation, install packages, test apps, and paste errors. That means the agent is often active during exactly the kind of messy workflow attackers exploit: a browser open to random pages, npm packages being installed, test scripts being executed, and local servers scattered across ports.

OpenCode's flaw fit that environment too well. A user did not need to paste a malicious prompt into OpenCode. They only needed the vulnerable version running while an untrusted local process or website reached its HTTP server. The coding agent became ambient attack surface.

This is a design lesson for the entire category. If an agent exposes local control APIs, those APIs need authentication, origin checks, capability scoping, and secure defaults. Tool vendors should assume that a developer workstation is full of untrusted code and untrusted browser content. The agent runtime has to defend itself from the rest of the machine.

The Engineering Miss

The embarrassing part of CVE-2026-22812 is that the vulnerability class is old. Missing authentication on command-execution endpoints is not an AI research frontier. Permissive CORS on an API that can run shell commands is not a model-alignment problem. These are baseline application-security controls.

That is why the incident belongs next to vibe-coded software failures. AI coding agents are being pushed into production workflows at speed, but the surrounding engineering still has to meet normal security standards. When it does not, users inherit a tool that can write code, read files, and run commands for anyone who can reach its helper server.

The OpenCode advisory credited CyberShadow for reporting the issue and noted that vulnerability verification and proof-of-concept testing were performed by the reporter. It also stated that code analysis, scoring, and documentation were assisted by Claude AI. That detail is a fitting footnote: AI can help describe a vulnerability, but it cannot replace the architecture decision that should have prevented the unauthenticated command server in the first place.

The patched version closed the known hole. The wider lesson remains open for every AI coding tool: local agent servers are not implementation details. They are security-sensitive interfaces, and if they can run a shell, they need to be treated like production infrastructure.