A critical vulnerability in the OpenCode AI coding agent created a route from an ordinary malicious website to command execution on a developer’s computer. The attack abused the product’s local web interface and package-upgrade mechanism, demonstrating that binding a service to localhost does not automatically make it safe from browser-originated requests.

The issue is tracked as GHSA-632h-h47v-g4x4 and affects OpenCode versions 1.14.30 through 1.18.21 when installed with npm, pnpm or Bun. Maintainer Anomaly corrected the problem in version 1.18.22. No CVE was requested, so security teams should use the GitHub advisory identifier when tracking remediation.

Upgrade feature accepted more than versions

OpenCode integrates language models into developer workflows and can expose a browser interface through the opencode serve or opencode web commands. By default, that service listens on 127.0.0.1:4096 and does not require authentication.

Datadog Security Labs found that the /global/upgrade endpoint passed a user-supplied target to a package-manager command intended to install a requested OpenCode version. The application expected a semantic version, but npm-compatible package specifications can also point to remote tarball URLs.

An attacker could therefore supply a hosted package archive containing a malicious package.json lifecycle script. When the package manager installed that archive, its preinstall instructions ran with the same privileges as the OpenCode process. On a developer workstation, those permissions can expose source code, credentials, signing material and cloud access tokens.

Why browser protections did not stop the exploit

The service was restricted to localhost, but a hostile page opened in the victim’s browser could still reach it. A normal JavaScript request with an application/json content type would trigger a cross-origin preflight and likely be blocked. Researchers instead used an HTML form submitted as a top-level navigation.

The form declared text/plain, a submission path not stopped by the protections that would apply to the JSON fetch. OpenCode’s raw request handler attempted to parse every body as JSON without first verifying the declared content type. By carefully choosing a hidden form field’s name and value, the attacker could make the browser generate valid JSON despite the plain-text declaration.

That JSON directed the upgrade endpoint to the malicious tarball. A victim needed only to visit the crafted page while an affected OpenCode web service was running. The chain combined two weaknesses: permissive parsing at the HTTP boundary and unsafe interpretation of the upgrade target.

Who was exposed

A system was vulnerable when it used one of the affected versions, installed OpenCode through npm, pnpm or Bun, and ran the web or serve mode. The service also needed to lack password protection, or the browser needed valid basic-authentication credentials already cached.

Public package figures cited by the researchers show that 82 vulnerable releases received more than 647,000 downloads between September 17 and 23, representing 38.9% of OpenCode downloads during that interval. Download counts do not equal unique installations and do not reveal how many users enabled the browser interface, but they illustrate the potential reach.

Patch and investigate suspicious package activity

Version 1.18.22 adds defense in depth. It validates the requested upgrade value as a semantic version, preventing arbitrary URLs, and replaces the raw-body handler with content-aware processing. The corrected endpoint rejects the demonstrated plain-text request with an HTTP 415 response.

• Upgrade to OpenCode 1.18.22 or a later release and restart all active processes.
• Confirm both the installed version and the package manager used for installation.
• Set OPENCODE_SERVER_PASSWORD whenever the browser interface is enabled.
• Do not expose the local service on broader network interfaces.
• Review package-manager logs, lifecycle-script execution and unexpected downloads.

Password protection reduces the attack surface but is not a substitute for patching because browsers may automatically send cached credentials. Organizations should also consider developer tools listening on localhost part of their application inventory. When those tools can install packages or run commands, their HTTP endpoints deserve the same input validation, authentication and monitoring applied to remote production services.

Source: Cyber Security News reporting on Datadog Security Labs research.