OpenCode AI Coding Agent Flaw Lets Malicious Websites Execute Code on Developer Machines

A critical attack path in OpenCode, an open-source AI coding agent, could let a malicious website execute commands on a developer’s computer.

Tracked as GHSA-632h-h47v-g4x4, the remote code execution vulnerability combines content-type confusion in OpenCode’s /global/upgrade API with unsafe handling of an attacker-controlled upgrade target. Anomaly fixed the issue in OpenCode 1.18.22.

OpenCode launched in June 2025 and integrates language models into developer workflows. Its website reports more than 208,000 GitHub stars and 16 million monthly developers, making the flaw noteworthy for software supply-chain security.

The affected component is OpenCode’s browser interface, started with opencode serve or opencode web, which listens on 127.0.0.1:4096 without authentication by default.

According to research published by Datadog Security Labs, versions 1.14.30 through 1.18.21 are vulnerable when installed using npm, pnpm, or Bun.

The /global/upgrade endpoint passed its target value into a package-manager command intended to install opencode-ai@VERSION. However, npm package specifications also accept URLs to remote tarballs.

Consequently, an attacker could substitute a hosted archive containing a malicious package.json preinstall lifecycle script, causing commands to run with the OpenCode process’s privileges.

Although the service binds to localhost, researchers showed that a hostile webpage could make the victim’s browser reach the local API. A conventional JavaScript fetch() request using application/json would trigger a CORS preflight and be blocked.

The exploit instead submits an HTML form as a top-level navigation, a route not stopped by CORS or Local Network Access protections. The crucial weakness was OpenCode’s raw request handler, which attempted to parse every request body as JSON without confirming that its declared content type was application/json.

By using enctype=”text/plain” and shaping a hidden field’s name and value, attackers could make the browser produce valid JSON. That body directed the upgrade endpoint to an attacker-controlled package tarball; installation then triggered its lifecycle script.

Exploitation required only that a user with an affected setup visit the crafted page while the OpenCode server was running.

A system is exposed when it runs OpenCode 1.14.30–1.18.21 installed through npm, pnpm, or Bun, operates serve or web, and either lacks password protection or has valid basic-authentication credentials cached in the browser.

Public npm figures cited by Datadog show that 82 vulnerable releases recorded more than 647,000 downloads between September 17 and 23, 2026, representing 38.9% of OpenCode downloads during that period.

Those totals do not show unique installations or how many users enabled the web service. Anomaly’s August 24 patch applies defense in depth. It validates the upgrade target as a semantic version, preventing arbitrary package URLs, and replaces the raw handler with a content-aware handler that rejects text/plain submissions.

OpenCode 1.18.22 returns HTTP 415 “Unsupported Media Type” for the demonstrated request. The code path arrived on April 29, with version 1.14.30 released the next day; Datadog discovered and privately reported it on August 11. No CVE was requested, so defenders should track the GitHub advisory identifier.

Developers should upgrade immediately to OpenCode 1.18.22 or later, restart active OpenCode processes, and verify their installed version and installation method.

They should also set OPENCODE_SERVER_PASSWORD whenever using the web interface, avoid exposing the service beyond localhost, and treat unexpected package-manager activity, lifecycle-script execution, or outbound downloads as possible compromise evidence.

Password protection reduces exposure but does not replace patching because cached browser credentials may still accompany malicious requests.

Cut every SOC alert investigation by 21 min. Power your SOC with instant IOC context for immediate response: Integrate TI Lookup in your SOC