GitHub Token Stealing via VS Code Web Editor Bug

A critical vulnerability was discovered in the web-based versions of Visual Studio Code (vscode.dev and github.dev) that allowed an attacker to steal a user's GitHub authentication token with a single click. The exploit leverages a chain of bugs involving how the editor handles notebooks and the installation of extensions, bypassing publisher trust systems to execute malicious code in the user's session.

The Exploit Chain: How Tokens are Stolen

The attack relies on a multi-step process to bypass security boundaries and exfiltrate sensitive credentials from the browser session.

Bypassing Publisher Trust

VS Code implements a publisher trust system to prevent the installation of untrusted extensions. However, the researcher discovered a way to bypass this screening:

  1. Local Workspace Extensions: Attackers can use local workspace extensions, which do not undergo the same publisher screening as marketplace extensions.
  2. CSP Bypass: While Content Security Policy (CSP) typically blocks JavaScript execution in local extensions, the attacker can use a local extension to bind a keyboard shortcut to the command install extension without checking publisher.
  3. The Payload: By triggering this shortcut, the attacker can force the installation of a second, "real" malicious extension that bypasses the trust system entirely.

Token Exfiltration via Notebooks

Once the malicious extension is installed, it can access the editor's internal state. The vulnerability is further amplified by how the web editor handles notebooks. If an attacker can get a victim to open a malicious notebook in a webview, they can potentially achieve Cross-Site Scripting (XSS). Because the web editor is signed into GitHub, this XSS can be used to access the GitHub authentication token stored in the session.

Mitigation and Resolution

Microsoft has implemented a stopgap fix to address this vulnerability. The primary changes include:

  • Notebook Confirmation: Adding a confirmation prompt when opening notebooks in the web version of VS Code to prevent automatic execution of malicious content.
  • Command Restrictions: Disabling the ability to skip the trusted publisher check via commands, closing the loophole used to install untrusted extensions silently.

These changes were merged into the VS Code codebase (referenced in PR #319705) around June 3rd.

Technical Analysis and Community Insights

Security researchers and developers have highlighted several systemic issues that made this vulnerability possible.

The "Original Sin" of Web-Based IDEs

Some community members argue that the fundamental design of github.dev is a security risk. By allowing the browser-based IDE to be fully signed into GitHub with broad permissions, the attack surface is significantly increased.

It's a pity that the web embedded VSCode editor is signed into GitHub at all... In a perfect world, it'd be awesome if the in-browser IDE launched with a temporary per-repo permission scope or token that allowed only pull and push to the repo in question; no github.com web session whatsoever.

Extension Trust Levels

Another critical point of failure is the trust level assigned to extensions. Currently, VS Code extensions run with the same trust level as the editor itself, meaning a compromised extension has broad access to the editor's environment.

The attack surface that makes this particularly nasty is that VSCode extensions run with the same trust level as the editor itself, and most developers have dozens installed without reviewing their permissions.

Summary of Risk

For developers, the primary takeaway is to exercise extreme caution when using web-based editors for repositories that are not fully trusted. The ability to exfiltrate tokens via a single click demonstrates the danger of combining broad session permissions with extensible plugin architectures in a browser environment.

Sources