`open` npm 7.2.0 to 10.2.0 runs PowerShell from a URL on Windows and WSL (CVE-2026-119025); MCP Inspector 2.12.0 and OpenCode 1.18.33 fixed

View raw markdownEdit on GitHub ↗

TL;DR

VulnCheck published CVE-2026-119025 on 2026-10-29 for the open npm package (219 million weekly downloads): on Windows and WSL, versions 7.2.0 up to but not including 11.0.0 placed the target URL unescaped inside a PowerShell command, so a URL containing a PowerShell subexpression ran commands as the user when the caller opened it. The record names two consumers that fed it URLs chosen by a remote MCP server during OAuth sign-in, MCP Inspector (fixed 2.12.0) and OpenCode (fixed 1.18.33). open fixed the escaping in 11.0.0 on 2025-11-15 with no security wording, and both consumers kept a ^10 pin for most of a year; run npm ls open in any MCP client or CLI you use on Windows and treat anything below 11.0.0 that opens remote URLs as affected.

What happened

The sink. open launches a URL or file in the default application. On Windows it builds a PowerShell command and runs it with -EncodedCommand; from 7.2.0 (npm 2020-08-21) through 10.2.0 (npm 2025-07-14) the target was wrapped in double quotes, inside which PowerShell evaluates $(...). Any string the caller passes through is therefore executed if an attacker chooses it. The maintainer's position since 2021, as Pillar Security's post records, was that sanitising untrusted input is the caller's job.

The fix that nobody labelled. Commit 274d704, "Fix PowerShell argument escaping", wraps the application name, the target and the arguments in PowerShell single quotes, where no expansion happens. It shipped in open 11.0.0 (npm 2025-11-15). The release notes list it among eight bug fixes beside "Require Node.js 20"; neither the commit nor the release mentions security or a CVE, and the commit links issues #318, #319 and #202. A consumer pinned to ^10.x or ^7.x received nothing, and no scanner flagged the pin, because there was no record to key on until 2026-10-29.

The record. CVE-2026-119025 (CNA VulnCheck, published 2026-10-29 11:24 UTC, CVSS 4.0 7.7 AV:N/AC:L/AT:P/PR:N/UI:P/VC:H/VI:H/VA:H, CVSS 3.1 7.5, CWE-78) lists three affected products: open 7.2.0 before 11.0.0, @modelcontextprotocol/inspector 2.0.0 before 2.12.0, and opencode 1.0.137 before 1.18.33. Its description names the path that matters to this audience: "OAuth authorization_endpoint values from malicious MCP servers". Credit: Eilon Cohen (Pillar Security).

MCP Inspector. GHSA-q978-78c7-phqw was published on the Inspector repository on 2026-10-21 (High, CVSS 3.1 8.8 AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H, CWE-78 and CWE-88, reporter eilonc-pillar). A remote MCP server that answers the connection with an OAuth challenge chooses the authorization_endpoint; Inspector opened it through open 10.2.0 in the CLI client, the TUI client and the web server (clients/cli/src/open-url.ts, clients/tui/src/utils/openUrl.ts, clients/web/server/web-server-config.ts). The advisory says no prompt, no model action and no local configuration change is needed; the code runs during connection. Affected 2.0.0 through 2.11.0, patched 2.12.0 (npm 2026-10-21). The 2.12.0 release notes say the release "fixes three vulnerabilities that affect every v2 release from 2.0.0 through 2.11.0", restrict URL opening to http(s), open the URL that was checked rather than the raw input, and upgrade open to v11; the other two are GHSA-vcc9-3xgm-p9v4 (Host header validation) and GHSA-m5pj-3536-3xcp (a response-size cap on /api/fetch). The vendor page printed "No known CVE" when read on 2026-10-29, the day the CNA record went out. Registry: 2.11.0 (2026-10-14) declares open: ^10.2.0; 2.13.0 (2026-10-28, newest) declares ^11.0.4; 720,577 weekly downloads (2026-10-22 to 10-28).

OpenCode. The same reporter's 2026-10-19 post on OpenCode is already its own file here: OpenCode pinned open 10.1.2, Anomaly fixed it in 1.18.33 (npm 2026-09-28) by moving to open 11.0.4 and adding a scheme check, and declined to request a CVE. The CVE now exists, filed against the library with OpenCode listed as an affected product. npm view opencode-ai dependencies.open returns nothing, because the package ships a bundle, so a dependency scanner keyed to this CVE will not see OpenCode's exposure; inventory by OpenCode version.

Who else pins it. Read on 2026-10-29 from the registry, with no code read: mcp-remote 0.15.2 (2026-10-20, 901,387 weekly downloads) declares open: ^10.1.0, which resolves inside the record's range. mcp-remote had its own URL-to-PowerShell bug in 2025 (CVE-2025-6514), fixed in its own code; whether its current code validates the URL before calling open was not read this run, so this file states the pin and not a verdict. netlify-cli declares ^11.0.0 (outside the range). firebase-tools declares ^6.3.0, below the record's lower bound of 7.2.0; the record does not speak to 6.x. @openai/codex, @google/gemini-cli, @anthropic-ai/claude-code, chrome-devtools-mcp, vercel, wrangler and the MCP TypeScript SDK declare no open dependency. Pillar's post lists three earlier CVEs on the same sink in other MCP clients (CVE-2025-6514 in mcp-remote, CVE-2025-58062 in openmcp-client, CVE-2025-10619 in sequa-mcp).

Why it matters here. The MCP OAuth flow hands a remote server a string your client will open in a browser. Every MCP client written in Node for Windows that reached for open before November 2025 and never bumped the pin has this shape, and until this record existed none of the tooling that reads lockfiles could say so.

Am I affected?

  • Windows or WSL only. macOS and Linux callers of open are not affected by this record.
npm ls open --all 2>/dev/null | grep -E 'open@(7\.([2-9]|[1-9][0-9])|[89]\.|10\.)'     # in a project: 7.2.0 through 10.x is the record's range
npm ls -g open --all 2>/dev/null | grep -E 'open@(7\.([2-9]|[1-9][0-9])|[89]\.|10\.)'  # globally installed CLIs and MCP clients
npm ls -g @modelcontextprotocol/inspector 2>/dev/null          # below 2.12.0 is affected
opencode --version                                              # 1.0.137 through 1.18.32 is affected
  • A hit in a package that opens URLs a remote party chooses (MCP OAuth, "open this link" flows fed from a server response) is the exposure. A hit in a package that only opens its own documentation URLs is a pin to fix, not an incident.
  • The code ran only when the client started an OAuth sign-in against the server; configuring a server or listing tools did not trigger it.

If you are affected

  1. Upgrade MCP Inspector to 2.12.0 or later (2.13.0 is current) and OpenCode to 1.18.33 or later.
  2. For any other client that resolved open below 11.0.0 on a Windows or WSL machine and signed in to a remote MCP server you do not control, treat the machine as having run that server's command: if an MCP server was malicious, then if your local AI agent was exploited.
  3. Maintainers: bump open to 11.x, validate the scheme and origin of any URL a remote party supplies before opening it, and prefer an argv-based opener; the Inspector advisory lists all three as fixes and the Pillar post says escaping alone is a layer.

Prevention

  • MCP hygiene: every field a server returns, including OAuth discovery documents, is untrusted input.
  • Package vetting checklist: a dependency fixed without a security label still needs the bump; keep ranges current on packages that touch the shell.

Sources