Another security researcher has chosen to forgo responsible disclosure and publicly release details of a critical zero-day vulnerability in Visual Studio Code, driven by deep frustration with Microsoft’s handling of previous reports. This time, the flaw targets the browser-based github.dev environment, allowing an attacker to steal a user’s GitHub OAuth token with a single click.
Why a Top Bug Bounty Hunter Abandoned Coordinated Disclosure
Ammar Askar, a security researcher affiliated with the Georgia Institute of Technology and a top contributor to GitHub’s bug bounty program, published the full details and a proof-of-concept exploit on his personal blog on June 2. He gave Microsoft’s Security Response Center (MSRC) just one hour of advance notice before the disclosure. He did not file a formal report through MSRC’s standard channels.
Askar’s decision was not made in haste. It was the culmination of a years-long pattern of perceived negligence from Microsoft. In 2023, Askar reported a Remote Code Execution (RCE) vulnerability in VS Code through the proper MSRC channels. According to Askar, Microsoft silently patched the flaw, refused to assign him a CVE, classified it as having “no security impact,” and deemed it ineligible for a bug bounty. He subsequently declared that he would release all future VS Code-related vulnerabilities as full disclosures.
The recent “Nightmare Eclipse” incident, where Microsoft reportedly threatened a researcher with legal action before backing down, has only intensified existing distrust within the security community. Askar’s frustration, however, predates that controversy particular and is rooted in a structural belief that MSRC systematically undervalues and disregards VS Code vulnerabilities.
How a Single Click on a github.dev Link Exposes All Repositories
The vulnerability exploits the OAuth token flow between github.com and the github.dev web-based code editor. When a user navigates a repository URL from github.com to github.dev, an OAuth token is POSTed to the editor’s domain to authenticate the session. The core design flaw is that this token is not scoped to the specific repository being opened. Instead, it grants full read and write access to every repository the user can access, including all private repositories.
Askar’s proof-of-concept attack chain works in several stages, all initiated when a victim clicks a malicious link to a github.dev repository.
The attacker prepares a repository containing a malicious Jupyter Notebook file, a VS Code local workspace extension, and a carefully crafted .vscode/extensions.jsoncodecodecodecodecode file designed to recommend a specific extension. Once the victim opens the repository in github.dev, the Jupyter Notebook’s embedded HTML executes JavaScript within the webview panel. VS Code has a deliberate architectural feature that relays keyboard events from the webview to the main editor via the postMessagecodecodecodecodecode API. While this is intended to allow keyboard shortcuts to function across different contexts, the exploit weaponizes it.
The injected script simulates a precise sequence of keystrokes to automatically accept a dialog that proposes installing the recommended local workspace extension. Because github.dev treats its workspace as a “trusted workspace,” the extension installs without any further publisher trust checks or user interaction. This first-stage extension has near-complete control over the environment.
From there, the local extension uses a custom keybinding to bypass publisher trust checks for a second extension from the VS Code Marketplace. This second extension is the final payload. It directly extracts the OAuth token from the browser’s context and uses it to query the GitHub API, exfiltrating data from all accessible repositories—including private ones—without any additional warnings.
Microsoft’s Emergency Fix and the Underlying Problem
Following Askar’s blog post, Microsoft deployed a server-side fix on June 3. The mitigation adds a confirmation dialog before opening any notebook files on github.dev and prevents the relaying of keyboard events from bypassing origin trust checks. Microsoft has stated that this remediation is service-side and requires no user action.
Alexandru Dima of the VS Code team has also commented that the desktop version of VS Code is not affected by this specific token theft scenarioikuha a statement that is accurate from a narrow perspective. However, as Askar himself points out, the fundamental mechanism of relaying keyboard input from webviews to the main editor exists in the desktop application as well. If an attacker were to successfully clone a repository and open a malicious notebook in the desktop version, the same core issue could potentially be exploited for remote code execution via the Node.js API.
As of this writing, no CVE identifier has been assigned for this vulnerability.
How to Protect Yourself After Opening github.dev
Users should be vigilant. If you have previously used github.dev, browsing data and cookies associated with the domain may allow a previously granted session to be reused without a fresh OAuth dialog. To force a new authentication prompt, clear all site data and cookies specifically for github.dev in your browser’s settings. Additionally, never click on github.dev links from unfamiliar or untrusted repositories. Treat them with the same caution as any other executable link.
A Systemic Failure at MSRC Is Driving Researchers Away
Askar’s case is not an isolated episode of personal grievance. His blog details a troubling pattern of VS Code vulnerabilities being dismissed by MSRC. In 2022, a Google researcher discovered an RCE in VS Code that took two months to patch and was ruled out of bounds for a bounty. A command injection vulnerability in the Git extension reported by SonarSource was also rejected. A more recent XSS vulnerability from STAR Labs was classified as “out of scope and low severity.”
There is evidence of a broader policy within Microsoft to exclude first-party extensions—those bundled with VS Code itself—from the bug bounty program entirely. Askar has publicly encouraged other researchers to follow his lead and adopt full disclosure for VS Code issues.
The irony is stark. Just weeks ago, in May, an attacker successfully used a malicious VS Code extension to exfiltrate data from approximately 3,800 internal GitHub repositories. The security model of the VS Code extension ecosystem itself is under intense scrutiny. And yet, MSRC has continued to relegate VS Code vulnerability reports to the sidelines. The recent “Nightmare Eclipse” case ended with Microsoft issuing a statement saying it had “no intent to sue” the researcher and acknowledging that “some of its responses have been inadequate.” But mere days later, another respected researcher has reached the identical conclusion: reporting to MSRC is not worth the effort.
The trust that Microsoft has eroded over years of opaque triage decisions and inconsistent bounty rewards will not be restored by a single public apology. Each new zero-day that is forced into the open through full disclosure is a testament to a system many researchers now see as fundamentally broken.
