A security firm has disclosed a critical remote code execution vulnerability in opencode, one of the most popular open-source AI coding agents, and the more troubling part is how it was handled: the fix shipped quietly a month ago with no security advisory and no CVE, meaning most enterprises have no way to know they were exposed. Pillar Security published the research on October 19.
opencode, published on npm as opencode-ai by the company Anomaly, counts roughly 3 million weekly downloads and 211,000 GitHub stars. Like other coding agents it reads local files, executes commands and connects to external systems - typically with the full privileges of the developer running it. The flaw Pillar found affects versions 1.0.137 through 1.18.32 on Windows and Windows Subsystem for Linux, and lets an attacker-controlled remote MCP server execute arbitrary code during the OAuth authentication handshake, with no additional user interaction or consent.
The mechanics are almost mundane. When a remote MCP server answers the OAuth 401 challenge, the authorization_endpoint string from its discovery response flows straight from the wire into a shell invocation through the browser-launching open and xdg-open packages, with no scheme validation or origin check. That is CWE-78, operating system command injection, and Pillar proposes a CVSS of 9.8. The payload does not need an exotic scheme: a perfectly ordinary HTTPS URL carries it, which means the protection everyone recommends - validating the URL scheme - does not stop it, and neither does the scheme denylist that the MCP SDK still ships as its default.
The blast radius follows from where coding agents live. A developer machine holds cloud credentials, SSH keys, git tokens and model-provider API keys - exactly the material an attacker wants. And the attack does not require the MCP server to be malicious when it was configured: the payload arrives in an HTTP response at connection time, so a later compromise, a hijacked registry entry, a typosquat or an expired domain can all trigger the same path. Connecting an agent to any remote MCP server is, in effect, credentialless delegation of trust.
None of the underlying bug class is new. The identical defect - same package family, same OAuth field - was published as CVE-2025-6514 at 9.6 critical in July 2025, and two more CVEs mapped the same sink that summer. opencode's vulnerable code was written in December 2025, well after the class was documented. The lesson Pillar draws is that commonly recommended fixes are incomplete, and that untrusted input reaching a shell remains live wherever HTTP responses drive local process launches.
The disclosure gap is the part that outlives this specific bug. Anomaly patched the issue in version 1.18.33, released September 28, but shipped it as a silent refactor and did not request a CVE, citing that malicious remote MCP connections fall outside the threat model. The consequence is mechanical: no vulnerability scanner, no dependency bot and no software-composition analysis will flag affected installations. Organizations running opencode on Windows or WSL need to inventory installations directly and upgrade, then review which remote MCP servers their agents trust.
The structural point is bigger than one agent. A remote MCP server is a third party speaking a protocol to a process on your laptop, which makes every MCP client a parser of untrusted input - the same category as a browser or a mail client, where every field of every response must be treated as attacker-controlled until proven otherwise. The past year of MCP security discussion has centered on prompt injection, which is real and unsolved. Pillar's finding is a reminder that the transport layer can break in more ordinary ways, and that an agent ecosystem growing this fast accumulates browser-class vulnerabilities at browser-class speed.
Comments (0)
Log in to join the discussion
Log InNo comments yet