Overview of CVE-2026-70094: Untrusted search path in Visual Studio Code via JavaScript Debugger auto attach

Introduction

Cloning a repository and opening it in Visual Studio Code is one of the most routine things a developer does, and CVE-2026-70094 turned that routine into a path to code execution. In VS Code 1.145.2 and earlier, JavaScript debugger auto attach settings shipped inside an untrusted workspace could influence which executable the editor launched at startup, so a malicious repository could run its own code before Workspace Trust had a chance to protect the user.

Microsoft rates the issue CVSS 3.1 8.8 (High) with a product severity of Important, and classifies it as CWE-426, Untrusted Search Path. At publication Microsoft reported "Exploited: No", "Publicly disclosed: No" and "Exploitation Less Likely". Independent reporting from OffSeq likewise found no indexed public exploit and no observed attack traffic. The fix shipped in VS Code 1.145.3 on November 10, 2026 as part of Patch Tuesday. The affected product is Visual Studio Code, not the separate Visual Studio IDE, and the vendor is Microsoft (the raw CVE feed listed the vendor as Unknown).

Technical information

Scoring and prerequisites

The published base vector is:

CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H

Microsoft's full vector adds E:U/RL:O/RC:C, giving a temporal score of 7.7 (unproven exploit maturity, official fix, confirmed report). The temporal fields do not lower the 8.8 base score.

The field that matters most is UI:R. The network attack vector reflects that the malicious content can be delivered remotely, but a user must open it. Microsoft's FAQ phrases this as opening a specially crafted file. The GitHub advisory is more specific, stating that the user only had to open the folder, with no debug session or task required.

Root cause: workspace-controlled executable lookup

MITRE defines CWE-426 as using an externally supplied search path to locate critical resources outside the product's direct control, so that an attacker can cause a program or library in an attacker-controlled location to be selected and executed. MITRE distinguishes this from CWE-427, which concerns planting content in a location already on the search path. Here, the issue is control over the lookup configuration itself.

According to Microsoft's advisory (GHSA-3grj-pfwj-fffm), the code that decided which executable to launch for JavaScript debugger auto attach read part of its configuration from the workspace. The relevant component is the JavaScript Debugger extension (ms-vscode.js-debug), which VS Code bundles. Its terminalOptions setting inherits environment and launch properties from js debug's Node terminal configuration.

VS Code lets an extension mark a setting as restricted. When a workspace is in Restricted Mode (untrusted), VS Code ignores workspace-level values for restricted settings found in that workspace's .vscode/settings.json, and only user-level or trusted values apply. Before the fix, terminalOptions was not marked restricted. That meant a cloned repository could supply terminal and auto attach options, including environment and launch properties, and the debugger would read them at startup when deciding what to launch. Workspace Trust never had a chance to intervene because the setting was not classified as something trust should gate.

Attack flow

Based on the advisory and patch, the sequence looks like this:

1. The attacker prepares a repository whose .vscode/settings.json supplies js debug terminal and auto attach options, including environment or launch properties that influence executable lookup.
2. The attacker gets the victim to clone or download the repository and open the folder in VS Code 1.145.2 or earlier.
3. The workspace opens in Restricted Mode, but because terminalOptions was not a restricted setting, its workspace values are still honored.
4. At startup, js debug's auto attach logic reads those values while deciding what to launch, and resolves an executable using the attacker-influenced configuration.
5. The attacker's code runs in the user's context, before the user has granted trust to the workspace.

What is not publicly documented

The public sources do not name the specific executable, file extension, environment variable or setting values involved, and we have not attempted to reconstruct them. The public js debug commits also reference MSRC case numbers rather than CVE IDs. Linking MSRC case 127395 to CVE-2026-70094 is an inference based on the advisory text and the fact that it is the only workspace configuration change in js debug 1.140.1.

Patch information

Fixed version: Visual Studio Code 1.145.3, released November 10, 2026. Microsoft's Security Update Guide lists 1.145.3 as the fixed build with remediation marked "Official Fix". The GitHub advisory is GHSA-3grj-pfwj-fffm, tracked in issue #347423 under the 1.145.3 Patch Tuesday milestone.

The fix in microsoft/vscode

The fix in the main repository is commit f25c662c6bfead64d1296c5e5d0669cbff91fa5c ("Merged PR 813: chore: update ms-vscode.js-debug"). It changes no editor logic. It upgrades the bundled JavaScript Debugger from 1.140.0 to 1.140.1 and pins the new VSIX by hash in product.json:

 			"name": "ms-vscode.js-debug",
-			"version": "1.140.0",
-			"sha256": "d535f02a47031671f8c988bb7e79d6fec1a881883d9c9fa15ff81f28eae98500",
+			"version": "1.140.1",
+			"sha256": "a30e6ca910fb3e68a29543f17ce8c1fdcdf215dad2c2b7fdce50fa4575b9fb5e",
+			"vsix": "resources/common/ms-vscode.js-debug.1.140.1.universal.vsix",

The VSIX now ships in the repository at resources/common/ms-vscode.js-debug.1.140.1.universal.vsix, so VS Code builds include the fixed debugger without downloading it separately.

The code change in vscode-js-debug

Comparing v1.140.0...v1.140.1 in microsoft/vscode-js-debug shows two security commits:

1. "fix: restrict terminal debug configuration" (Msrc Case Id 127395, merged as PR 809)
2. "fix: harden diagnostic webview content" (Msrc Case Id 137262), which escapes data and adds a CSP to the diagnostics webview, and does not match this advisory

The first commit adds a restricted flag to js debug's settings schema generator and sets it on terminalOptions:

@@ export type DescribedAttribute =
     docDefault?: string;
     enum?: Array;
     enumDescriptions?: MappedReferenceString[];
+    restricted?: boolean;
     tags?: Tag[];
   };

@@ const configurationSchema: ConfigurationAttributes = {
     type: 'object',
     description: refString('configuration.terminalOptions'),
     default: {},
+    restricted: true,
     properties: nodeTerminalConfiguration.configurationAttributes as { [key: string]: JSONSchema6 },
   },

With restricted: true, workspace-supplied values for terminalOptions are dropped until the user grants trust. This matches the advisory's statement that startup auto attach no longer trusts workspace-controlled executable lookup configuration in an untrusted workspace.

Why this design matters

The fix works at the trust boundary. Rather than trying to validate every executable path or environment variable a repository might supply, Microsoft classified the entire setting as gated by Workspace Trust. That closes the startup execution path with one declarative schema change. It also means the fix arrives only through the updated bundled debugger, which happens automatically when VS Code is updated to 1.145.3.

Getting the update

• Windows and macOS: VS Code updates automatically by default when new releases are published.
• Linux: With the VS Code repository correctly installed, the system package manager handles updates like other packages.
• Manual: Use Check for Updates in VS Code, or the official security update download linked from the Microsoft advisory.

The 1.145 release notes describe Update 1.145.3 as addressing security issues but do not name this CVE. The link between the CVE and the build comes from Microsoft's security advisory.

Workspace Trust remains useful as a supplementary layer, but Microsoft documents that a malicious extension can execute code while ignoring Restricted Mode, and the advisory states no CVE-specific workaround. This vulnerability is itself an example of workspace content reaching execution before trust applied, which is why the update, not the trust setting, is the remediation.

Affected systems and versions

• Visual Studio Code 1.0.0 up to, but not including, 1.145.3 (CVE record and NVD, using Microsoft's data)
• The GitHub advisory describes the vulnerable behavior as present in 1.145.2 and earlier
• Vulnerable builds bundle ms-vscode.js-debug 1.140.0, and fixed builds bundle 1.140.1
• Vulnerable configuration: opening an untrusted workspace or folder whose .vscode/settings.json supplies js debug terminal and auto attach options
• Platforms: the advisory's product table does not restrict the issue to a single platform, and VS Code 1.145.3 is distributed for Windows, macOS and Linux
• Not affected by this advisory: the separate Visual Studio IDE product

Vendor security history

VS Code has a very large footprint. The 2026 Stack Overflow Developer Survey reports 70.9% usage (9,350 of 13,193 respondents), first among listed development environments. That is survey adoption with multiple selections allowed, not exclusive market share.

This CVE follows two earlier 2026 VS Code issues in the same broad area of workspace trust enforcement:

• CVE-2026-81376 (published September 8, 2026, GHSA-r2gr-w3c8-wvqv): a crafted workspace could cause a connection to an attacker-controlled service while still in Restricted Mode, potentially allowing access to local data or execution in the user's context without trust being granted. Fixed in 1.136.2.
• CVE-2026-70334 (GHSA-q2f8-hh8x-wpc2): restricted settings embedded as nested objects in .vscode/settings.json could be applied without trust. Microsoft fixed this with recursive configuration handling, also in 1.136.2.

In each case Microsoft shipped code fixes rather than relying on Restricted Mode as sufficient, and advised that avoiding untrusted workspaces does not replace updating. These are distinct vulnerabilities, and they do not show that CVE-2026-70094 shares their mechanism. Together, though, they illustrate that workspace settings are a recurring trust boundary in the editor. Microsoft's repository security policy directs researchers away from public GitHub issues and toward its formal security reporting channel.

References

• NVD: CVE-2026-70094
• CVE Record: CVE-2026-70094
• Microsoft Security Update Guide: CVE-2026-70094
• Microsoft Security Guidance Advisory: CVE-2026-70094
• microsoft/vscode security advisories (GitHub API)
• microsoft/vscode issue #347423
• microsoft/vscode commit f25c662c6bfead64d1296c5e5d0669cbff91fa5c
• microsoft/vscode js debug compare v1.140.0 to v1.140.1
• Visual Studio Code 1.145 release notes
• CVE Services API record
• MITRE CWE-426: Untrusted Search Path
• VS Code documentation: Workspace Trust
• VS Code FAQ
• GHSA-r2gr-w3c8-wvqv: Workspace Trust bypass through attacker controlled services
• GHSA-q2f8-hh8x-wpc2: Restricted Mode bypass via nested configuration objects
• microsoft/vscode Security Policy
• vuln.management advisory
• OffSeq Threat Radar entry
• Casco CVE entry
• Tenable plugin: Security Update for Microsoft Visual Studio Code (October 2026)
• Zero Day Initiative: The November 2026 Security Update Review
• CISA Known Exploited Vulnerabilities Catalog
• Stack Overflow Developer Survey 2026: Technology data
• Stack Overflow Developer Survey 2026: Dev IDEs