Microsoft paid a researcher US$4,000 for reporting a Visual Studio Code flaw that lets a booby-trapped workspace slip past Workspace Trust, a bug that carries a 9.6 CVSS score. The fix shipped in September, so the news here is the bounty write-up and what it shows about how vendors price developer-tool bugs.
What happened
On 19 October 2026, details emerged of a US$4,000 award paid by Microsoft to researcher Sam Chen, who publishes as Samchen, for reporting CVE-2026-81376. It is a security feature bypass in Visual Studio Code’s Workspace Trust mechanism. To be clear from the outset, this is not a new or unpatched vulnerability. Microsoft published its advisory on 8 September 2026 and the fix arrived in VS Code 1.136.2. What is new is the researcher’s account of the bounty process and the size of the reward, which GBHackers reported on 19 October.
According to that account, Chen reported the issue to the Microsoft Security Response Center (MSRC) on 23 May 2026. MSRC confirmed it on 3 June, and on 9 June the bounty team judged it eligible for US$4,000 under Microsoft’s Open Source Bounty Program. Chen says the award reflected an Important rating and a high-quality report. Chen went public on 10 September, two days after the advisory.
The CVE record tells a slightly different story on severity. The National Vulnerability Database (NVD) shows a CVSS 3.1 base score of 9.6, rated Critical, using Microsoft’s own vector. Microsoft’s Security Update Guide, however, gives the bug an aggregate severity of “Important”. Microsoft’s machine-readable advisory also lists six separate acknowledgements, which suggests Chen was not the only person to find this weakness.
The technical picture
Workspace Trust is the safety catch VS Code applies to any folder or repository you have yet to vet. While Restricted Mode is active, VS Code curbs or switches off features that could run content controlled by the project, such as tasks, debugging, certain workspace settings and some extension behaviour. The aim is to let developers inspect strange code without it acting on their machine.
Microsoft’s FAQ for CVE-2026-81376 explains the failure in plain terms. An attacker persuades a user to open a specially crafted workspace. That workspace can then make VS Code connect to a service the attacker controls and get round the Workspace Trust restrictions. If it works, the attacker can read local data or run code as the logged-in user. Microsoft is explicit that user interaction is needed, but that the user “does not need to trust the workspace”. That is exactly the case the feature exists to handle.
The root cause is listed as CWE-1023, incomplete comparison with missing factors, alongside CWE-693, protection mechanism failure. The CVSS vector (AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:H/A:H) explains the high score. The attack is network-reachable and needs no privileges, and the scope change reflects code breaking out of the trust boundary. Microsoft marked the flaw as not publicly disclosed and not exploited at release, with an assessment of “Exploitation Less Likely”. No full write-up or proof of concept is public yet.
Why it matters for UK organisations
Developer workstations are some of the most valuable endpoints in any UK organisation, and often among the least controlled. A typical engineer’s laptop holds source code, SSH keys, cloud command-line credentials, package registry tokens and, all too often, a route into production. If a flaw lets an untrusted repository run code in that user’s context, the editor stops being the issue. The real exposure is everything the developer can reach.
The delivery route is familiar: a candidate’s take-home coding test, a supplier’s sample project or a fork shared in a chat channel. Workspace Trust was built for these moments, but this bug shows it is a mitigation, not a hard boundary.
For UK firms running vulnerability disclosure or bounty programmes, the reward is the more interesting part. A US$4,000 award for something scored 9.6 will look low to many researchers. Microsoft’s bounty tables key off its own severity rating and the programme, not the CVSS base score. Still, the gap between “Critical” in the CVE record and “Important” in the vendor’s rating is the kind of mismatch that leaves researchers feeling short-changed, and it shapes where skilled hunters spend their time.
Expert view
In my experience, CVSS and bounty tables answer different questions. CVSS describes the worst plausible technical impact in a vacuum. A vendor’s severity rating, and the reward attached to it, weighs real-world preconditions such as user interaction, attack complexity and how likely mass exploitation is. Needing someone to open a malicious workspace is a real barrier, and Microsoft’s “Exploitation Less Likely” call reflects that. Even so, social engineering a developer into cloning a repository is hardly exotic. When we test organisations, a convincing pretext aimed at an engineer is one of the more dependable ways to get a foothold.
The six acknowledgements also matter. When several researchers independently find the same weakness, it usually means the area is getting a lot of attention, increasingly with AI-assisted tooling. Where vendors pay only the first valid reporter while crediting the rest, they risk putting people off reporting at all. Researchers who see a critical-scored bypass priced at a few thousand dollars may decide their time is better spent elsewhere.
I regularly see Workspace Trust, or similar “safe mode” features in other IDEs, listed in risk registers as the control that makes it acceptable for engineers to open unvetted code on corporate machines. A bypass like this, patched or not, should prompt a rethink. The control reduces risk; it does not remove it.
What to do now
- Confirm patch levels. Check every VS Code installation is on 1.136.2 or later and has been restarted, including portable installs and Insiders builds. This maps directly to the Cyber Essentials security update management control.
- Inventory developer tooling. Bring IDEs and their extensions into your software asset inventory so that update compliance can actually be measured, not assumed.
- Keep Workspace Trust on, but do not rely on it alone. Leave Restricted Mode enabled by default. Open unfamiliar repositories, coding tests and third-party samples in a disposable container, virtual machine or cloud development environment that holds no credentials.
- Reduce what a compromised editor can reach. Use short-lived cloud credentials, keep production access behind separate privileged accounts, and remove long-lived tokens from developer laptops. This supports the Cyber Essentials user access control and secure configuration requirements.
- Watch developer endpoints. Make sure EDR coverage includes engineering machines, and alert on editors spawning shells or making unexpected outbound connections.
- Review your own bounty or VDP terms. If you run a programme, publish how rewards relate to severity, decide how you will treat duplicate reports, and say so clearly to researchers.
Bottom line
CVE-2026-81376 was fixed in September, so this is not an emergency for anyone who keeps VS Code up to date. The bounty write-up is still worth reading for two reasons. It shows that Workspace Trust can fail, so untrusted code belongs in an isolated environment, not on a credential-rich laptop. And it puts a price on that kind of bypass, US$4,000 for a 9.6, that researchers and programme owners alike will take note of.
Sources
- GBHackers: Microsoft Pays Researcher $4,000 for Discovering Critical VS Code Security Bypass Flaw
- Microsoft Security Response Center: CVE-2026-81376 Visual Studio Code Security Feature Bypass Vulnerability
- Microsoft Security Response Center: CSAF advisory for CVE-2026-81376
- NIST National Vulnerability Database: CVE-2026-81376
