al-ice.ai

The Notification, the Install Link, and the Redirect: Three MCP RCEs in VS Code 1.145

AI Vulnerabilities & CVEs by al-ice.ai Editorial

Microsoft’s November Patch Tuesday did not just patch Windows and Exchange — it patched the trust VS Code extends to MCP servers. On 10 November 2026 the microsoft/vscode repository published three security issues, all affecting VS Code 1.145.2 and earlier and all fixed in 1.145.3, in which a malicious or compromised MCP server — or a malicious install link for one — reaches code execution with the user’s permissions. The most severe, CVE-2026-120779 (CVSS 3.1 9.6, network attack vector, no privileges required), turns an MCP elicitation notification into a command link. Alongside it, CVE-2026-114171 (8.8) weaponizes vscode:mcp/install links carrying unsafe input definitions, and CVE-2026-119983 (8.8) lets a server redirect the legacy SSE transport to an endpoint of its choosing. Three different surfaces, one common failure: the client treated server-controlled data as interface, configuration, and routing it could trust.

The notification that ran commands (CVE-2026-120779)

MCP elicitation is the protocol’s human-in-the-loop escape hatch: the server asks the user for input mid-task, and the client renders the request. Issue #347426 (GitHub advisory GHSA-66hq-jw93-462h) describes what went wrong in the fallback notification path for those requests: server-controlled message content could be interpreted as an interactive VS Code command link, so a malicious MCP server only needed the user to click the crafted notification to cause command execution. NVD published the CVE record the same evening (19:20 UTC, currently Awaiting Analysis) with the vector AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H — network-reachable, low complexity, changed scope, full confidentiality/integrity/availability impact. The two fix commits (305e248, e3a4962) mitigate it by rendering elicitation messages as literal text and validating the request payload before display. That fix shape is the tell: somewhere in the fallback path, server text was being handed to a renderer that understood command:-style links. Rendering untrusted content as literal text is the oldest lesson in client security, and MCP elicitation re-taught it — the “human approval” step only counts as a control if the thing the human reads cannot itself act.

The install link that smuggled inputs (CVE-2026-114171)

The second flaw moves the attack one step earlier, to installation. Issue #347430 (advisory GHSA-crhv-2887-p3xr) describes a crafted MCP installation link that could include unsafe input definitions or variable values which were not rejected before installation; once installed, those values could resolve a command-backed input and execute a command with the user’s permissions. The preconditions are social-engineering-shaped — the attacker must convince the user to open the malicious link and approve the installation — which is exactly why NVD’s 8.8 (AV:N/AC:L/PR:N/UI:R, UI misrepresentation of critical information, security-feature bypass) still matters: install links are designed to be shared, pasted into chats and docs, and approved quickly. The fixes (6f1f0c4, 82e93d6) do three things: validate install-link inputs, reject unsupported command-backed variables, and make the configuration being installed more explicit. That third item is the durable one. The install dialog is a trust boundary, and until this fix it showed the user something less than the full truth about what they were approving — the same UI-as-security-boundary problem this site has tracked in Claude Code’s don’t-ask-again settings and, in a different editor, Visual Studio Copilot’s trailing-dot RCE.

The transport that followed the server anywhere (CVE-2026-119983)

The third flaw is the quietest and arguably the most structural. Issue #347428 (advisory GHSA-4x35-6qr8-ww48) concerns the legacy SSE transport in VS Code’s MCP client: a remote server could supply a new transport endpoint that VS Code used without sufficiently validating its origin and protocol, so follow-up requests went to an unintended destination — with credential exposure or further code execution as the downstream consequence. The single fix commit (1ea9a4c) validates server-provided SSE endpoints before establishing the follow-up transport. NVD’s classification is instructive: it filed this one as SSRF (8.8, security-feature bypass), not code injection — the client was turned into a request-forger by its own server. The SSE transport is legacy and Streamable HTTP is the direction of travel, but “legacy transport still supported” is where redirect-validation gaps live longest, and Microsoft’s own workaround — disable or remove affected legacy SSE servers, prefer a trusted transport — says the quiet part out loud. This one pairs naturally with Chainlit’s CVE-2026-120492 SSRF from earlier this month: two different MCP-adjacent stacks, same missing check on where the next request goes.

What this trio actually says about MCP client security

Read together, the three issues map the full lifecycle of a malicious server relationship: onboarding (the install link), steady-state interaction (elicitation notifications), and transport (endpoint redirection). Every stage assumed a benign server, and every stage handed the server a capability — rendered markup, configuration values, routing — that a malicious one converts into execution. That is the same arc as the seven-CVE batch across the MCP reference servers and Desktop Commander and the mcp-go/ChatCLI OAuth resource confusion: the protocol keeps failing at the seams where one party’s data becomes another party’s action. Two mitigations in the advisories deserve emphasis because they cut against convenience defaults. First, Microsoft explicitly says to review the displayed server configuration before approving installation — install-and-go is the enemy. Second, for SSE users, the guidance is to remove the legacy transport until updated, not merely to patch eventually. And the broader context sharpens the point: agents are already installing deprecated, unpatched MCP servers from training memory against mostly unpinned public configs — every server your editor will happily connect to is only as safe as the client’s distrust of it, and this Patch Tuesday showed that distrust had three holes.

What to actually do

  1. Update VS Code to 1.145.3 or later — all three flaws affect 1.145.2 and earlier, and all three are fixed in 1.145.3. Fleet owners should treat this as the November must-patch alongside the Outlook zero-day riding the same Patch Tuesday batch.
  2. Treat every MCP install link as untrusted input: do not open vscode:mcp/install links from chats, docs, or web pages you would not otherwise execute code from, and read the full displayed configuration — especially input definitions and variable values — before approving.
  3. Audit connected MCP servers, starting with legacy SSE ones: disconnect or remove any SSE-transport server you cannot vouch for, prefer Streamable HTTP or stdio transports from trusted sources, and re-add servers only after updating.
  4. Assume past connections may have been observed: the SSE flaw explicitly contemplates credential exposure via misdirected follow-up requests — rotate tokens, API keys, and database credentials that transited VS Code MCP sessions to servers you do not fully control.

Our verification was read-only. We read all three microsoft/vscode security issues first-hand in full via the GitHub API (issues #347426, #347430, and #347428, all created 10 November 2026 ~18:16–18:17 UTC, all closed and labeled candidate/security, each with summary, attacker preconditions, affected versions 1.145.2 and earlier, fix in 1.145.3, fix-commit hashes, workarounds, and GHSA/MSRC references) and the full NVD JSON for CVE-2026-120779 (published 10 November 2026 19:20 UTC, Awaiting Analysis, 9.6 AV:N/AC:L/PR:N/UI:R/S:C), CVE-2026-114171 (published 10 November 2026 19:19 UTC, Awaiting Analysis, 8.8 UI misrepresentation), and CVE-2026-119983 (published 10 November 2026 19:20 UTC, Awaiting Analysis, 8.8 SSRF). The fix commits and MSRC pages are cited via the issues’ own references and were not independently re-fetched. BleepingComputer’s Patch Tuesday coverage is carried as reported for batch context only. We ran no editor, connected to no MCP server, crafted no link, and contacted no vendor. Brave Search was used for discovery only.

Sources: