Overview of CVE-2026-119985: Visual Studio Code Incorrect Authorization Let Remote Workspaces Bypass Workspace Trust

Introduction

A Workspace Trust flaw in Visual Studio Code allowed a .code-workspace file served over HTTP or HTTPS to be treated as trusted before the user made any trust decision. Workspace settings capable of starting processes could therefore take effect after a single opened link. In the 2026 Stack Overflow Developer Survey, 70.9% of respondents to the development environment question (9,350 of 13,193) reported using VS Code, so the gap between opening content and trusting content is relevant to a large share of developer workstations.

Microsoft tracks the issue as CVE-2026-119985, classifies it as CWE-863 (Incorrect Authorization), and assigns a CVSS v3.1 base score of 8.3 (High) with a vendor severity of Important. The fix shipped in Visual Studio Code 1.145.3 on November 10, 2026, as part of Patch Tuesday. This post covers the root cause, traced through the upstream commit, along with the documented attack sequence and the affected version range.

Technical information

Root cause: network workspaces took the virtual resource shortcut

Workspace Trust is the mechanism VS Code uses to decide whether a workspace's settings, including settings that start processes such as MCP server definitions, may run before the user approves them. Untrusted workspaces open in Restricted Mode, which Microsoft documents as limiting automatic code execution through terminals, tasks, debugging, workspace settings, extensions, and AI agents.

Microsoft's advisory GHSA-g3fj-wc2g-v3j5 states that when VS Code opened a .code-workspace file over HTTP(S), it could treat the resulting workspace as trusted before the user decided. The fix commit shows two separate causes in two different layers.

Layer 1: the trust service. In src/vs/workbench/services/workspaces/common/workspaceTrust.ts, the function isTrustedVirtualResource() automatically trusted any virtual resource unless its scheme appeared on a short deny list. Before the fix, that list contained only vscode-vfs (GitHub Repositories) and the agent host scheme:

return isVirtualResource(uri) && uri.scheme !== 'vscode-vfs' && uri.scheme !== AGENT_HOST_SCHEME;

Network-backed URIs using http: or https: were not on that list, so a workspace configuration file fetched over the network passed straight through as a trusted virtual resource.

Layer 2: the startup prompt. In src/vs/workbench/contrib/workspace/browser/workspace.contribution.ts, WorkspaceTrustUXHandler deliberately skipped the modal startup trust prompt for virtual workspaces:

// Don't show modal prompt for virtual workspaces by default
if (isVirtualWorkspace(this.workspaceContextService.getWorkspace())) {
	this.updateWorkbenchIndicators(false);
	return;
}

A network workspace therefore never presented the dialog that would normally give the user a chance to stay in Restricted Mode. Fixing only the trust service would have left users without a prompt; fixing only the prompt would have asked a question whose answer had already been assumed.

Why user interaction and absent trust approval coexist

The CVSS vector records user interaction as Required, because the victim must open the supplied link. Opening content and approving its execution are separate decisions, though. According to the advisory and freenode's reporting, the authorization failure sits between them: settings were applied before the explicit trust decision. A statement such as "the user never clicked Trust" is therefore not evidence that an affected build prevented execution.

Attack flow

Based on the MSRC advisory, the GitHub advisory, and freenode's report, the documented sequence is:

1. The attacker hosts a crafted .code-workspace file on an HTTP or HTTPS server. The file contains workspace settings that start processes, for example MCP server definitions pointing at an attacker-controlled process.
2. The attacker creates a malicious link or web page and uses social engineering to persuade the target to open it in Visual Studio Code.
3. VS Code opens the workspace whose configuration URI uses http or https. Because those schemes were missing from the exclusion check in isTrustedVirtualResource(), the workspace is treated as trusted.
4. Because the workspace is virtual, WorkspaceTrustUXHandler skips the startup trust prompt.
5. The workspace settings take effect without an explicit trust decision, and a process-starting setting can launch an attacker-controlled process, giving code execution in the user's connected development environment.

Microsoft rates attack complexity as High and states that particular protocol settings or configurations must be present for exploitation. The reviewed advisory does not enumerate those conditions, and no complete exploit or reproducible testing procedure has been published, so we do not speculate beyond the sequence above.

CVSS breakdown

Microsoft's base vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:H:

• Attack Vector: Network. Delivery happens over a network via a link or web page.
• Attack Complexity: High. Success depends on particular conditions.
• Privileges Required: None. No prior attacker authorization is needed.
• User Interaction: Required. The user must open the supplied link.
• Scope: Changed. Impact can extend beyond the vulnerable component's security authority.
• Confidentiality, Integrity, Availability: High.

Microsoft also publishes a 7.2 temporal score with exploit maturity Unproven, remediation level Official Fix, and report confidence Confirmed. NVD has not supplied an independent CVSS assessment, so the displayed score originates from Microsoft.

Exploitation status

Microsoft's publication assessment lists Exploited: No, Publicly disclosed: No, and Exploitation Less Likely. OffSeq reports no indexed Metasploit or Exploit DB module, no public Nuclei template, and no traffic seen by its Mirage sensors. The CISA KEV catalog version 2026.11.10 has no entry for this CVE, and CISA's November 10, 2026 notice adding six exploited vulnerabilities does not include it. No threat actor, campaign, or indicator set has been attributed. Active exploitation is not publicly confirmed in the reviewed material, but that material does not show it is impossible.

Patch information

Microsoft fixed CVE-2026-119985 in Visual Studio Code 1.145.3, released on November 10, 2026 for Patch Tuesday. The MSRC entry lists build 1.145.3 as the security update and rates the remediation level "Official Fix". The GitHub advisory GHSA-g3fj-wc2g-v3j5 marks versions < 1.145.3 as vulnerable and names a single upstream commit as the fix: d8e03ca86c6ef9ae33c5f288d5394d91d2b36ccf, titled "workspace: require trust for network workspaces". It was written by Connor Peet and carries the trailer Msrc-Case-Id: 146814. Tracking issue #347425 sits in the 1.145.3 "Patch Tuesday" milestone.

Trust service change

The patch adds http and https to the exclusion check using the matchesSomeScheme helper:

-import { Schemas } from '../../../../base/common/network.js';
+import { matchesSomeScheme, Schemas } from '../../../../base/common/network.js';
...
 	private isTrustedVirtualResource(uri: URI): boolean {
-		// `vscode-vfs` (e.g. GitHub Repositories) and `vscode-agent-host`
-		// (remote agent host folders) represent real, writable resources where
-		// code can run or files can change, so they must go through normal
-		// workspace trust rather than being auto-trusted as virtual resources.
-		return isVirtualResource(uri) && uri.scheme !== 'vscode-vfs' && uri.scheme !== AGENT_HOST_SCHEME;
+		// Network, repository, and agent host resources can carry executable workspace configuration.
+		return isVirtualResource(uri) && !matchesSomeScheme(uri, Schemas.http, Schemas.https, 'vscode-vfs', AGENT_HOST_SCHEME);
 	}

The new comment states the principle behind the change: any resource that can carry executable workspace configuration must go through normal trust evaluation rather than the virtual resource shortcut. The fix still relies on a deny list, so any future virtual scheme capable of carrying executable configuration would also need to be added explicitly.

Startup prompt change

With automatic trust removed, the user has to be asked. The patch checks whether any workspace folder, or the workspace configuration file itself, uses http or https, and keeps the "no prompt" path only for virtual workspaces that are not network backed:

 		// Don't show modal prompt for virtual workspaces by default
-		if (isVirtualWorkspace(this.workspaceContextService.getWorkspace())) {
+		const workspace = this.workspaceContextService.getWorkspace();
+		const isNetworkWorkspace = workspace.folders.some(folder => matchesSomeScheme(folder.uri, Schemas.http, Schemas.https)) ||
+			!!workspace.configuration && matchesSomeScheme(workspace.configuration, Schemas.http, Schemas.https);
+		if (isVirtualWorkspace(workspace) && !isNetworkWorkspace) {
 			this.updateWorkbenchIndicators(false);
 			return;
 		}

The check covers workspace.configuration as well as workspace.folders because a remote .code-workspace file can open with no folders at all, as the regression test demonstrates. A folders-only check would miss exactly the scenario described in the advisory.

Regression tests

The commit adds 37 lines to workspaceTrust.test.ts. A single test, run once for http and once for https, builds a workspace whose only element is a remote configuration URI (<scheme>://example.test/workspace.code-workspace) and checks the full trust lifecycle:

• Initial state: the URI is not trusted and the workspace is not trusted, but trust can be set.
• After setWorkspaceTrust(true): both the URI and the workspace are trusted, and the configuration URI is the only entry in getTrustedUris().
• After setWorkspaceTrust(false): the workspace is untrusted again.

These tests pin down the intended behavior. A network workspace starts in Restricted Mode, only an explicit user decision grants trust, and that decision can be revoked.

Net effect and how to apply it

The change totals 45 additions and 7 deletions across three files. Remote http and https workspaces now follow the same rules as local folders: no automatic trust, a startup prompt, and process-starting workspace settings held back until trust is granted. Install the 1.145.3 security update from the download page listed in the MSRC entry, or let VS Code update itself, then confirm that the reported version is 1.145.3 or later.

Interim precautions

For installations that cannot be updated immediately, freenode recommends avoiding remote .code-workspace links from untrusted sources and downloading and reviewing configuration files before opening them locally. Microsoft's Workspace Trust documentation advises leaving unfamiliar folders in Restricted Mode, while also noting that Workspace Trust cannot prevent a malicious extension from executing code. These measures reduce exposure, but they do not correct the vulnerable behavior in affected builds.

Affected systems and versions

• Product: Microsoft Visual Studio Code.
• Affected range: from 1.0.0 up to, but not including, 1.145.3 (CVE record). The GitHub advisory expresses this as < 1.145.3.
• Fixed version: 1.145.3 and later.
• Vulnerable configuration: opening a workspace whose configuration file or folders use the http or https scheme, for example a .code-workspace file delivered through a link or web page. Microsoft notes that particular protocol settings or configurations must be present, but does not list them.
• Not sufficient: the 1.136.2 releases that fixed CVE-2026-81376 and CVE-2026-78462 predate this fix and do not address CVE-2026-119985.

Vendor security history

Microsoft maintains VS Code as an openly developed project (Code OSS, MIT license) with monthly updates, and its SECURITY.md directs reporters to Microsoft's security reporting process instead of public issues. Two advisories published on September 8, 2026 involve the same general trust boundary:

• CVE-2026-81376 (GHSA-r2gr-w3c8-wvqv): a specially crafted workspace could connect to an attacker-controlled service while open in Restricted Mode. Incomplete enforcement of Workspace Trust restrictions while processing nested configuration objects could allow local data access or code execution without the user granting trust. Fixed in 1.136.2 by correctly filtering restricted settings.
• CVE-2026-78462 (GHSA-2cmq-rv52-5rf6): a crafted repository could configure an attacker-controlled remote agent host and grant it local file access; opening the repository was required, trusting it was not. Fixed in 1.136.2 by reading remote agent host addresses and persisted file permission grants only from global configuration.

The pre-existing deny list in isTrustedVirtualResource() already excluded vscode-vfs and the agent host scheme, and CVE-2026-119985 extends it to http and https. Taken together, these advisories show consistent corrective action and a recurring class of problems where workspace-supplied configuration reaches sensitive behavior before or around the trust decision. They do not establish that CVE-2026-119985 is the same defect, a regression, or part of any campaign.

References

• NVD entry for CVE-2026-119985
• CVE Record for CVE-2026-119985
• Microsoft Security Update Guide: CVE-2026-119985
• GitHub Security Advisory GHSA-g3fj-wc2g-v3j5
• Fix commit d8e03ca: workspace: require trust for network workspaces
• GitHub API: fix commit metadata
• GitHub API: security advisory metadata
• Tracking issue #347425
• NVD API record
• Visual Studio Code 1.145 release notes
• VS Code Workspace Trust documentation
• freenode: VS Code trusted remote workspaces before users decided
• OffSeq Threat Radar entry
• vuln.management advisory
• CISA Known Exploited Vulnerabilities feed
• CISA: Six Known Exploited Vulnerabilities added, November 10, 2026
• GHSA-r2gr-w3c8-wvqv (CVE-2026-81376)
• GHSA-2cmq-rv52-5rf6 (CVE-2026-78462)
• microsoft/vscode security advisories
• microsoft/vscode SECURITY.md
• microsoft/vscode repository
• Stack Overflow Developer Survey 2026: Dev IDEs