The VS Code Zero-Day That Hands Over Your GitHub Keys — What Your Team Must Do Now

On 2 June 2026, security researcher Ammar Askar publicly dropped a proof-of-concept for a zero-day vulnerability in GitHub.dev — the browser-based version of Visual Studio Code — that lets an attacker steal a victim’s GitHub OAuth token with a single click. No social-engineering marathon, no elaborate phishing kit. One crafted link, one click, and the attacker walks away with read-write access to every repository the victim can reach, including private ones.

The disclosure was unconventional: Askar bypassed Microsoft’s Security Response Centre (MSRC) entirely, citing previous incidents where his reports were silently patched without credit. Full exploit code is already public. Microsoft has since stated the issue is “mitigated for our services,” but the lessons for development teams run far deeper than a single patch.

TL;DR

• A zero-day in GitHub.dev allows one-click theft of GitHub OAuth tokens via VS Code’s webview message-passing system — granting full read/write access to all accessible repositories, not just the one you opened.
• The attack chain exploits webview sandbox weaknesses: malicious JavaScript simulates keystrokes to open the Command Palette and install a rogue extension from the local workspace, bypassing publisher verification.
• VS Code Desktop is not directly affected, but the broader pattern — IDEs as trusted execution environments with broad credential access — applies everywhere.
• Microsoft says the issue is mitigated server-side, but teams should still clear github.dev site data, audit OAuth token scopes, and review extension trust policies immediately.
• This is the third major IDE-targeting attack in 2026 (after GlassWorm and the Copilot co-author incident), confirming that developer tooling is now a first-class attack surface.

How the Attack Works

The exploit is elegant in its simplicity, which makes it all the more dangerous. Here is the chain:

1. The OAuth Token Handoff

When you open a repository on github.dev, GitHub authenticates the session by POSTing an OAuth token to the browser-based VS Code instance. As Askar noted, this token is not scoped to the specific repository you opened — it carries full access to every repo your account can reach. That is the first problem: an overly broad token sitting in a browser context.

2. Webview Sandbox Escape via Keystroke Simulation

VS Code uses webviews for rendering Markdown previews, Jupyter notebooks, and other rich content. These webviews are sandboxed — in theory. In practice, the message-passing channel between the webview and the main editor frame had insufficient isolation. Malicious JavaScript running inside a crafted notebook could simulate keydown events that propagated to the main editor window.

The exploit uses this to trigger Ctrl+Shift+P — opening the Command Palette — then types commands to install an extension from the workspace’s .vscode/extensions folder. Because local workspace extensions bypass the normal publisher verification and trust dialogue, the rogue extension installs silently.

3. Token Exfiltration

The freshly installed extension intercepts the OAuth token from the session context and phones home. From there, the attacker queries the GitHub API to enumerate every accessible repository — public, private, and internal — and can clone, modify, or inject code at will.

Why This Matters Beyond the Patch

Microsoft’s server-side fix addresses this specific exploit chain. But the underlying architecture problem — that IDEs are now trusted execution environments with ambient credential access — is not going away.

The IDE as Attack Surface

This is the third significant IDE-targeting attack in 2026 alone. In February, the GlassWorm attack used Zig-compiled native binaries hidden in VS Code extensions to achieve cross-IDE infection. In April, the Copilot co-author debacle revealed that metadata was being silently injected into commits without developer consent. Now, a webview sandbox bypass hands over OAuth tokens.

The pattern is clear: attackers have realised that compromising a developer’s IDE gives them the same access as compromising the developer’s machine, often with less friction. Your IDE has your SSH keys, your API tokens, your Git credentials, and now — through features like GitHub.dev — your OAuth sessions.

The Scope Problem

The most troubling aspect of this vulnerability is the token scope. When GitHub.dev receives an OAuth token, it gets access to everything the developer can see. There is no principle of least privilege at work here. If a junior developer opens a notebook link and gets compromised, the attacker potentially gains access to every private repository that developer touches — including shared organisation repos containing production secrets, deployment configurations, and proprietary code.

This is a systemic design choice, not a bug. Many platform-level OAuth integrations use broadly scoped tokens for convenience. The trade-off between user experience and security has, once again, defaulted to convenience.

The Disclosure Debate

Askar’s decision to skip MSRC and go straight to full disclosure is controversial, but it highlights a real tension in the security community. When researchers feel that responsible disclosure leads to silent patches and no credit, the incentive structure breaks down. For development teams, the takeaway is pragmatic: assume that zero-days will be disclosed publicly, sometimes with working exploit code, and plan your response posture accordingly.

What Your Team Should Do Right Now

Immediate Actions (Today)

1. Clear github.dev site data. In your browser, navigate to Settings → Cookies and Site Data → Manage On-Device Site Data, and clear everything for github.dev. This invalidates any cached tokens.
2. Audit GitHub OAuth app authorisations. Go to GitHub → Settings → Applications → Authorised OAuth Apps. Revoke anything you do not recognise or no longer use.
3. Review recent repository access logs. Check your organisation’s audit log for unexpected API calls, particularly repository enumeration or clone operations from unfamiliar IP addresses.

Short-Term Hardening (This Sprint)

1. Restrict workspace extension installation. In your VS Code settings (desktop and profiles), set "extensions.autoCheckUpdates": false and consider using an extension allowlist via extensions.allowed policies in managed environments.
2. Adopt fine-grained personal access tokens. GitHub’s fine-grained PATs let you scope access to specific repositories with specific permissions. Migrate away from classic tokens wherever possible.
3. Enforce browser-level controls for github.dev. If your organisation uses a managed browser or endpoint management, consider restricting github.dev access to approved devices only.

Strategic Changes (This Quarter)

1. Treat your IDE as a security boundary. Add IDE configuration, extension policies, and credential management to your threat model. If you are not already auditing what extensions your team runs, start now.
2. Implement credential rotation automation. Use tools like GitHub’s secret scanning, git-secrets, or Gitleaks in your CI/CD pipeline. Automate token rotation so that a stolen credential has a limited blast radius.
3. Adopt a zero-trust posture for developer tooling. Every tool in your developer workflow — IDE, terminal, package manager, CI runner — should be treated as a potential compromise point. Segment credentials, use short-lived tokens, and monitor for anomalous access patterns.

The Bigger Picture

We have been saying it all year: the developer workstation is the new perimeter. The tools we use to build software — our IDEs, our package managers, our CI/CD pipelines — are now first-class targets. The VS Code zero-day is not an isolated incident; it is part of a sustained campaign by threat actors who have realised that compromising the software supply chain at the developer level is the highest-leverage attack available.

For organisations building software, this means security can no longer be something that happens after code is written. It needs to be embedded in the tools, the workflows, and the culture of your development team — from the IDE settings on day one to the deployment pipeline on release day.

At REPTILEHAUS, we help teams build secure development workflows from the ground up — from DevSecOps pipeline design to credential management architecture and security audits. If your team needs help hardening your developer tooling against these emerging threats, get in touch.

📷 Photo by Caspar Camille Rubin on Unsplash