Microsoft Pays Researcher $4,000 for Discovering Critical VS Code Security Bypass Flaw

Microsoft awarded security researcher Sam Chen US$4,000 for reporting a flaw in Visual Studio Code that could let an attacker bypass Workspace Trust protections.

The issue, tracked as CVE-2026-81376, affects VS Code versions earlier than 1.136.2 and has a critical CVSS score of 9.6. Microsoft has fixed the flaw; users should update to version 1.136.2 or later.

Workspace Trust is meant to limit what VS Code can do when a user opens a project they have not reviewed. In Restricted Mode, the editor blocks or limits features that could run code from that workspace.

The flaw mattered because it could weaken this safety boundary and expose a developer’s local data or allow code to run with the user’s permissions.

Researcher Sam Chen, who publishes under the name Samchen, noted that the issue was hidden in VS Code’s Workspace Trust mechanism and could be used to reach remote code execution.

His public post says the full technical write-up is not yet available, so the exact exploit steps have not been disclosed there. No malware was identified in the report; this is a vulnerability disclosure, not a report of a malware campaign.

Critical VS Code Security Bypass Flaw

Microsoft’s advisory describes CVE-2026-81376 as an “incomplete comparison with missing factors.” The National Vulnerability Database lists it as a security feature bypass that can be triggered over a network.

Its CVSS 3.1 vector includes user interaction, meaning the victim must take an action, and rates the possible impact to confidentiality, integrity, and availability as high.

In practical terms, the danger is not simply that a project contains suspicious code. Workspace Trust exists to reduce the risk of opening unfamiliar files and folders by limiting features that could run project-controlled content.

Microsoft’s advisory says a specially prepared workspace could connect to an attacker-controlled service and bypass those restrictions. If successful, exploitation could expose local data or run code in the context of the logged-in user.

That user context can be valuable. Developers often work with source code, credentials, cloud tools, and access tokens on the same machine. A flaw that lets untrusted workspace content cross a security boundary could therefore put more than the editor at risk.

The advisory does not say that every workspace can exploit the issue, and the available public write-up does not provide a complete proof of concept. Readers should avoid treating unconfirmed exploit details as established facts.

The issue also fits a wider pattern in developer-tool security: project files and editor settings can become part of the attack path when software gives them too much trust.

GBHackers has previously reported on VS Code extension security flaws and on a malicious repository targeting IDE users. Those cases involve different vulnerabilities and campaigns, but they show why developers should carefully inspect unfamiliar code and workspace content.

Researcher’s report and Microsoft’s response

Chen reported the issue to Microsoft Security Response Center (MSRC) on May 23, 2026. MSRC opened the case for review that day, confirmed the issue on June 3, and moved it into development.

On June 9, Microsoft’s bounty team found the report eligible for a US$4,000 award under its Open Source Bounty Program. The researcher’s post says MSRC classified the report as Important, High Quality, and an Improper Input Validation issue when determining the award.

Microsoft later confirmed that the problem had been fixed and said an advisory would be published on the next Patch Tuesday. The advisory appeared on September 8, and Chen publicly disclosed the issue on September 10.

This sequence reflects the usual responsible-disclosure process: a researcher reports a weakness privately, the vendor checks and fixes it, and public details follow.

The bounty recognizes the report, but the award amount does not indicate how severe the vulnerability is. Severity comes from the technical assessment; here, NVD records Microsoft’s CVSS score as 9.6, Critical.

Other reports have shown how trust decisions in developer tools can affect real-world exposure. For example, GBHackers covered a VS Code web editor vulnerability involving GitHub OAuth tokens and a separate Amazon Q extension issue involving workspace configuration.

These are not the same bug, but they underline the need to treat repositories, settings, and extensions as security-sensitive.

NVD lists Visual Studio Code versions from 1.0.0 to before 1.136.2 as affected. Users should install version 1.136.2 or later, then confirm that the editor has restarted and is running the updated build.

Organizations should check managed and developer-owned devices, including machines that may have more than one VS Code installation.

Until systems are updated, developers should be cautious with projects received through unsolicited links, code tests, or unfamiliar repositories.

Keep Workspace Trust enabled and use Restricted Mode while reviewing unknown projects. Microsoft explains that the feature limits workspace settings, tasks, debugging, and other functions that may run project-controlled content.

Because Chen’s full write-up is still pending, teams should not rely on speculative exploit instructions or assume that a particular indicator proves exploitation.

Apply the patch, review unusual activity on developer endpoints, and follow Microsoft’s advisory for updates. This is especially important for workstations that hold source code, signing keys, cloud credentials, or access to production systems.

Indicators of compromise (IoCs):-

Note: IP addresses and domains are intentionally defanged (e.g., [.]) to prevent accidental resolution or hyperlinking. Re-fang only within controlled threat intelligence platforms such as MISP, VirusTotal, or your SIEM.

Join 16,000+ SOC teams using ANY.RUN to streamline threat investigations and reduce manual effort. Explore for your team