Security researcher Ammar Askar has disclosed a one-click attack affecting the web version of Visual Studio Code that allows an attacker to silently steal a victim’s GitHub access token. The implications are significant. With a single compromised token, an attacker can potentially gain read and write access to every GitHub repository available to the victim, including private repositories. As Askar noted, simply clicking a malicious link could result in the theft of a token capable of accessing and modifying all repositories associated with the victim’s account.
How a Trusted Development Workflow Created an Unexpected Attack Vector
The attack leverages a legitimate GitHub feature known as github.dev. Users can open a repository, replace “github.com” in the URL with “github.dev,” and immediately launch a browser-based version of VS Code. This lightweight environment allows users to browse files, review pull requests, edit code, and commit changes without installing any software locally.
This convenience relies on OAuth authentication. When a user launches github.dev, GitHub transfers an OAuth token to the browser-based editor so it can interact with repositories on the user’s behalf. The core issue is that this token is not restricted to the repository being viewed. Instead, it inherits the user’s broader GitHub permissions, potentially granting access to every repository available to that account. As a result, compromising a single token can expose an entire development environment.
Cross-Origin Communication as a Security Boundary
VS Code is built on Electron, a framework that combines web technologies with desktop application functionality. Because arbitrary JavaScript execution inside the main application could effectively lead to remote code execution, VS Code isolates potentially risky content using components known as webviews.
Webviews are essentially sandboxed iframes rendered from a different origin than the main editor interface. The editor itself operates within one security boundary while the webview runs within another. Browser-enforced same-origin protections are intended to prevent content running inside the webview from directly accessing VS Code’s internal APIs or Electron’s powerful system-level capabilities. In theory, malicious content rendered within a webview should remain confined to that isolated environment.
However, complete isolation introduces usability challenges. Users expect actions such as clicking links, using keyboard shortcuts, searching, and interacting with embedded content to behave consistently throughout the application. To bridge these separate security contexts, VS Code uses the browser’s postMessage() mechanism, allowing controlled communication between webviews and the main application window. This messaging system enables features such as synchronized previews, interactive notebooks, and embedded content while preserving the intended security boundaries.
When Sandboxed Content Starts Controlling the Editor
The weakness emerged from the way VS Code forwards keyboard events between webviews and the main application. To ensure keyboard shortcuts continue functioning while users interact with content inside a webview, VS Code captures key presses and forwards them to the trusted editor environment.
According to Askar’s research, malicious JavaScript running inside an untrusted webview could fabricate keyboard events and send them to the main application as though they originated from the user. This effectively allows an attacker to simulate specific keyboard shortcuts within the trusted editor environment.
The attack was not as simple as opening the Command Palette and typing arbitrary commands. The Command Palette uses a standard HTML input element that does not process these synthetic keystrokes in a useful way. While attackers could navigate menu items using simulated arrow keys and Enter presses, they could not directly inject arbitrary text. As a result, the exploit had to be carefully constructed around existing VS Code keyboard shortcuts and built-in functionality.
Building a Compromise Through Trusted VS Code Functions
The exploitation process demonstrates how seemingly minor functionality can be chained together into a significant compromise.
The first stage involves extension recommendations. VS Code allows repositories to recommend extensions through a .vscode/extensions.json file. When a user opens such a workspace, VS Code may display a notification suggesting installation of the recommended extension. The attacker’s repository contains a preconfigured recommendation pointing to malicious functionality.
The next step exploits a keyboard shortcut associated with notification handling. Rather than attempting to interact with the Command Palette, the attacker triggers a forged Ctrl+Shift+A shortcut. This shortcut invokes the command responsible for accepting the primary action associated with the most recent notification. In practice, this allows the malicious extension recommendation to be accepted automatically.
Microsoft introduced publisher trust protections in VS Code version 1.97, requiring users to explicitly trust unknown extension publishers before installation. Under normal circumstances, this protection would block the attack. However, Askar discovered a method of bypassing the trust prompt using local workspace extensions. Because github.dev workspaces are considered trusted environments, extensions embedded directly within the workspace can avoid triggering the normal publisher verification process.
Another obstacle appeared in the form of Content Security Policy restrictions affecting locally loaded extensions within the web-based version of VS Code. To overcome this limitation, the attacker leveraged VS Code’s extension framework itself. By defining custom keyboard shortcuts within an extension’s package.json file, the attacker could reliably invoke privileged commands through synthetic key events. A custom shortcut such as Ctrl+F1 was configured to execute the extension installation command while bypassing publisher trust validation. This effectively completed the installation process.
From Extension Installation to Repository Access
Once the malicious extension becomes active, the final stage begins. The extension retrieves the GitHub OAuth token originally supplied by GitHub to the github.dev environment. With that token in hand, the attacker can interact directly with GitHub APIs and enumerate repositories accessible to the victim’s account. The attack not only steals the token itself but can also collect detailed information about private repositories available to the victim, significantly expanding the attacker’s visibility into the target’s development environment.
The complete attack requires only a brief sequence of automated actions. The malicious script waits for the extension recommendation notification to appear, simulates acceptance of the prompt, waits for the extension installation process to complete, triggers the custom shortcut, and finally installs and activates the attacker’s extension. From there, token theft and repository enumeration occur automatically.
Impact on VS Code Desktop
Although the attack initially attracted attention because of its impact on github.dev, the underlying weakness also exists within the desktop version of VS Code. Exploitation is somewhat more difficult because the victim must first clone and open a malicious repository locally. Nevertheless, the same trust boundary issue remains present.
The implications are potentially more severe in desktop environments. Askar noted that combining this flaw with a separate cross-site scripting vulnerability affecting a webview could potentially result in full remote code execution against the victim’s workstation. In such a scenario, the attack would move beyond token theft and into complete system compromise.
Why the Risk Extends Beyond the Browser
Despite the seriousness of the vulnerability, several existing security controls helped prevent even more severe outcomes. VS Code employs multiple layers of protection beyond basic iframe isolation, including strict Content Security Policies and content sanitization mechanisms such as DOMPurify.
For example, certain extension marketplace pages are configured with restrictive policies that completely prohibit script execution. These protections prevented attackers from escalating the vulnerability into a straightforward one-click remote code execution attack through malicious extension content. Without these safeguards, the impact could have been substantially worse.
Practical Steps to Mitigate the Threat
Users who have never previously used github.dev may still encounter an authentication prompt before accessing the service. This additional interaction can provide an opportunity to recognize suspicious behavior and abandon the session before the attack proceeds.
A more practical mitigation involves clearing cookies and local storage associated with github.dev. Removing stored session data forces reauthentication and can disrupt attack scenarios that rely on existing authenticated sessions. Browser settings typically provide options to remove site-specific cookies and locally stored data.
The concern is that users who have previously authenticated to github.dev and retained their session data may remain susceptible. Because github.dev lacked robust CSRF protections at the time of disclosure, attackers could potentially redirect users into malicious workflows through seemingly harmless links.
Timeline of Disclosure and Microsoft’s Mitigation Efforts
Askar publicly disclosed the vulnerability on June 2, 2026, after notifying GitHub security contacts approximately one hour before publication. The researcher cited previous frustrations with the handling of earlier VS Code security reports as one factor influencing the decision to proceed with rapid public disclosure.
Microsoft responded quickly. On June 3, 2026, the company deployed a temporary mitigation that introduces additional confirmation prompts when opening notebooks within the web version of VS Code and prevents commands from bypassing trusted publisher verification. These changes effectively block the specific exploitation chain described in the research.
Security Implications for Browser-Based Development Platforms
This vulnerability serves as a powerful reminder that security weaknesses often emerge from the interaction between usability and trust. The ability to forward keyboard shortcuts from isolated webviews was introduced to improve the user experience, ensuring that keyboard-driven workflows function consistently across the application. Yet that convenience inadvertently created a pathway through an otherwise well-designed security boundary.
The incident also highlights the importance of proper token scoping. Had the GitHub token been restricted solely to the repository being accessed through github.dev, the resulting impact would have been dramatically reduced. Instead, a broadly privileged token transformed a relatively clever user-interface abuse technique into a compromise capable of exposing an organization’s entire source code portfolio.