VS Code Flaw Enabled One-Click GitHub Token Theft

A security researcher disclosed a severe vulnerability in GitHub.dev that allowed attackers to steal GitHub OAuth tokens through a single malicious link. The stolen tokens granted full read and write access to all repositories the victim could access—including private ones.

Security researcher Ammar Askar made the vulnerability public on June 2, one hour after notifying GitHub's security team. Microsoft rolled out a fix within 24 hours, and the company confirmed no customer action is required.

The Attack Chain

The vulnerability exploited a message-passing mechanism between VS Code's main window and webviews—the sandboxed iframes used for features like Markdown previews and Jupyter notebooks. Here's how it worked:

1. Victim clicks a malicious link pointing to a crafted notebook file on GitHub.dev
2. Malicious JavaScript executes within an untrusted webview
3. The exploit simulates keystrokes to trigger Ctrl+Shift+P and open the Command Palette
4. An attacker-controlled extension installs locally, bypassing publisher trust checks
5. The extension captures GitHub OAuth tokens passed to GitHub.dev
6. Tokens exfiltrate to attacker infrastructure

As Askar explained: "Just by clicking a link, it's possible to steal a GitHub token that can read and write to your repos, including private ones."

The attack required no special permissions, no user confirmation beyond the initial click, and left minimal forensic traces. A developer reviewing what looked like a legitimate notebook would have no indication their credentials were being harvested.

Scope and Impact

The vulnerability affected GitHub.dev specifically—the browser-based VS Code experience accessible via the . keyboard shortcut on any GitHub repository. VS Code Desktop installations were not vulnerable to this attack vector.

The stolen OAuth tokens had broad permissions. Unlike tokens scoped to individual repositories, the credentials passed to GitHub.dev provided access to every repository the victim could reach. For developers with access to organizational private repos, a single successful attack could expose an entire company's source code.

This type of developer-focused attack follows patterns we've documented in supply chain compromises targeting npm packages and other development ecosystems. Attackers increasingly recognize that compromising developer credentials provides access to far more valuable targets than compromising end users.

Timeline

• June 2, 2026 (morning): Askar notifies GitHub security team
• June 2, 2026 (one hour later): Askar publishes technical details and proof-of-concept
• June 3, 2026: Microsoft deploys server-side mitigation
• June 3, 2026: Microsoft confirms fix, states no customer action required

The disclosure approach was controversial. Giving Microsoft one hour before publishing working exploit code left virtually no time for the company to assess impact or deploy mitigations. Askar's decision to proceed anyway reflects ongoing frustration in the security research community about vendor responsiveness—though in this case, Microsoft moved quickly once the disclosure went public.

Why Developer Tools Are High-Value Targets

GitHub hosts over 100 million repositories. A vulnerability that steals authentication tokens from developers using GitHub.dev potentially exposes:

• Private source code and intellectual property
• API keys and secrets committed to repositories
• CI/CD configurations that could enable supply chain attacks
• Access to organization-wide resources through compromised developer accounts

The attack didn't require compromising GitHub's infrastructure—just getting a developer to click a link. Social engineering developers is easier than hacking enterprise security controls, and the payoff can be significantly larger.

We've seen similar thinking in campaigns like JINX-0164, where attackers posed as recruiters to target cryptocurrency developers. Once you have a developer's credentials, you have access to their entire professional ecosystem.

Mitigation Confirmed

Microsoft's statement was brief: "This issue has been mitigated for our services and no customer action is required."

The server-side fix means users don't need to update anything—the vulnerable behavior no longer exists in GitHub.dev. However, developers who clicked suspicious links in the window between disclosure and patch should audit their GitHub activity for:

• Unexpected repository clones or forks
• New deploy keys or personal access tokens
• Commits they didn't make
• Webhooks added to repositories

GitHub's security logs can surface most of these indicators. Rotating personal access tokens as a precaution isn't a bad idea if you actively used GitHub.dev during the vulnerability window.

Broader Lessons

Browser-based development environments trade security isolation for convenience. Running code editing in a web browser exposes authentication tokens to browser-based attack vectors that desktop applications avoid.

The webview message-passing vulnerability is a reminder that sandboxing is hard. The assumption that untrusted content in a webview couldn't influence the parent application turned out to be wrong. Similar trust boundary violations appear regularly in complex applications—the Chrome zero-days we cover often exploit similar architectural assumptions.

For organizations, this incident raises questions about cloud-based development tools. The convenience of GitHub.dev comes with exposure to vulnerabilities that wouldn't affect local development environments. Security teams should understand what browser-based tools their developers use and what credentials those tools can access.