Critical GitHub Token Vulnerability Exposes User OAuth Tokens

Key Takeaways

• A critical vulnerability in Visual Studio Code’s webview implementation allows attackers to steal GitHub OAuth tokens.
• The flaw affects both the browser-based github.dev and desktop VSCode versions, granting read/write access to all private repositories.
• Exploitation requires only a single malicious link click, with the attack chain completing silently in under a minute.
• Security researcher Ammar Askar publicly disclosed the bug with a full proof-of-concept on June 2, 2026.
• Users are advised to clear site data for github.dev and avoid suspicious links until an official patch is released.

A severe security vulnerability has been identified within the webview component of Visual Studio Code, enabling attackers to compromise and exfiltrate GitHub OAuth tokens. This critical flaw grants unauthorized read/write access to all private repositories associated with a victim’s account. The attack can be initiated with a single click on a malicious link.

Security researcher Ammar Askar publicly revealed the details of this vulnerability, including a full proof-of-concept, on June 2, 2026. Askar cited previous unsatisfactory interactions with the Microsoft Security Response Center (MSRC) as the reason for opting for immediate full disclosure, notifying a GitHub security contact just an hour before publication.

The core of the issue lies within GitHub’s browser-based VSCode editor, accessible via github.dev. When a user transitions from github.com to github.dev for any repository, the system automatically transmits an unscoped OAuth token to the github.dev session. Crucially, this token provides comprehensive access to every repository the user can access, not just the specific one they opened. This broad access, coupled with the extensive in-browser TypeScript codebase of VSCode, presents a lucrative target for malicious actors.

VSCode’s Webview Security Model

VSCode employs webviews, essentially <iframe> elements, to isolate potentially untrusted content. These webviews are served from a distinct vscode-webview:// origin, separate from the main editor’s vscode-file:// origin. This cross-origin isolation is designed to prevent JavaScript within a webview from directly interacting with VSCode’s Node.js or editor APIs. Features such as Markdown previews and Jupyter notebook outputs are rendered within these sandboxed iframes.

For communication between the editor and webviews—for instance, to synchronize a Markdown preview with the current line in the editor—VSCode utilizes the Window.postMessage() API. This API allows structured JavaScript objects to be passed securely between the two isolated origins.

To enhance user experience, VSCode’s webview implementation registers a did-keydown event handler. This handler forwards all keyboard events from within the webview to the main VSCode window via postMessage. This mechanism ensures that keyboard shortcuts, such as Ctrl+Shift+P, remain functional even when a user’s focus is inside a webview.

However, this design introduces a critical flaw: untrusted JavaScript running within a webview can synthesize fake keydown events, effectively simulating user keyboard input. This compromises the intended security boundary between “Dangerous APIs” and “Untrusted User Content,” as the postMessage channel for keyboard forwarding inadvertently bridges them.

Exploit Chain: From Click to Token Exfiltration

Ammar Askar’s proof-of-concept, published on June 2, 2026, details a five-step exploit chain that leverages various VSCode behaviors to achieve full token exfiltration:

1. Initial JavaScript Execution: The attack begins by exploiting features like Jupyter Notebooks, where malicious .ipynb files can use an HTML image tag with an onerror handler to execute arbitrary JavaScript within a webview iframe. Similarly, attackers can leverage the .vscode/extensions.json file in VSCode, typically used for extension recommendations.
2. Silent Malicious Extension Installation: The JavaScript payload waits for an extension recommendation notification from VSCode. It then dispatches a synthetic Ctrl+Shift+A keydown event, which corresponds to the “Notifications: Accept Notification Primary Action” command. This allows for the silent installation of a malicious extension. Instead of installing from the Marketplace, which would trigger a publisher trust dialog, the attacker can place the harmful extension directly into the .vscode/extensions/ directory.
3. Bypassing Publisher Trust: This direct placement bypasses the trusted publisher check, relying solely on workspace trust. Workspaces on github.dev are always treated as trusted, making them vulnerable.
4. Overcoming CSP Restrictions: Due to Content Security Policies (CSPs), local extensions cannot load worker scripts from origins other than vscode-cdn.net. To circumvent this, the attacker introduces a custom keybinding (e.g., Ctrl+F1) via package.json. This keybinding calls the workbench.extensions.installExtension function with skipPublisherTrust set to true.
5. Token and Repository Exfiltration: Once installed, the malicious extension gains access to the preloaded GitHub OAuth token. It then makes requests to https://api.github.com/user/repos to enumerate all accessible private repositories. Finally, both the stolen OAuth token and the list of private repositories are exfiltrated.

The entire JavaScript payload executes in less than a minute, requiring no user interaction beyond the initial click on the malicious link.

This vulnerability impacts both the browser-hosted github.dev and the desktop version of VSCode. While the github.dev variant directly steals OAuth tokens, the desktop version requires the victim to clone and open the attacker’s repository. On desktop, a successful exploit can lead to full Remote Code Execution (RCE) because VSCode extensions have unrestricted access to Node.js APIs, including child_process.

The stolen GitHub OAuth token is not scoped to a single repository, meaning an attacker can silently read, modify, or push to every private repository the victim has access to. Furthermore, since github.dev does not implement CSRF tokens, any link on the internet can redirect a user into this attack.

Askar acknowledged that VSCode’s defense-in-depth mechanisms helped limit the exploit’s “blast radius.” For instance, a strict Content Security Policy (script-src ‘none’) on extension Markdown preview pages prevents arbitrary JavaScript execution there, blocking a simpler one-click RCE path via a malicious Marketplace extension page. Additionally, the use of DOMPurify for sanitizing rendered Markdown helps close off cross-site scripting vectors.

What You Should Do

• Clear Site Data: Immediately clear all site data for github.dev in your browser. (For Chrome: Click the URL bar icon → Cookies and site data → Manage on-device site data → delete all github.dev domains). This action will re-enable an initial warning dialog, providing an opportunity to avoid the attack.
• Exercise Caution with Links: Avoid clicking on any unfamiliar or suspicious github.dev links until Microsoft or GitHub issues an official patch.
• Audit Extensions: Review all installed extensions on github.dev and uninstall any that are unrecognized or seem suspicious.
• First-Time Users: Be aware that users who have never visited github.dev and have cleared their local storage are protected by an initial consent dialog, which provides a layer of defense.

Disclaimer: HackersRadar reports on cybersecurity threats and incidents for informational and awareness purposes only. We do not engage in hacking activities, data exfiltration, or the hosting or distribution of stolen or leaked information. All content is based on publicly available sources.