A security researcher has published a working exploit that steals a GitHub OAuth token from github.dev with a single click on a crafted link. The token grants read and write access to every repository the victim can reach: public, private, and organizational. Passwords and 2FA do not block it. As of June 3, 2026, no patch has been confirmed and no CVE has been assigned. The disclosure is trending on Hacker News.
Ammar Askar disclosed the vulnerability on June 3, 2026. His writeup documents a four-step exploit chain against github.dev, the browser-based VSCode instance that loads when you press . on any GitHub repository page. Each step abuses a VSCode feature that is individually reasonable: keyboard-event forwarding to webviews, JavaScript execution in Jupyter markdown cells, auto-loading of local workspace extensions, and a keybinding API that can install extensions while bypassing publisher-trust checks. Chained together, they let attacker-controlled JavaScript simulate keystrokes, install a malicious extension, and exfiltrate the session’s OAuth token.
How the Four-Step Chain Works
The attack begins when a victim clicks a github.dev link that opens a malicious repository. That repo contains two payloads: a Jupyter notebook with an <img onerror> handler that executes JavaScript inside a VSCode webview, and a local workspace extension sitting in .vscode/extensions/ that VSCode loads automatically because trusted workspaces load local extensions without publisher verification.
The notebook’s JavaScript waits for VSCode to finish loading, then dispatches synthetic KeyboardEvent objects through the browser DOM. VSCode’s webview forwards did-keydown events to the main window so that keyboard shortcuts work inside notebooks and preview panes. Nothing prevents untrusted JavaScript from dispatching the same events. The script sends Ctrl+Shift+A to accept a recommended-extension notification, which loads the attacker’s local extension along with its contributed keybinding. Then it sends Ctrl+F1 to trigger that keybinding, which calls workbench.extensions.installExtension with skipPublisherTrust:true, installing an attacker-controlled extension from the VSCode Marketplace with publisher-trust checks bypassed entirely.
That extension reads the GitHub OAuth token from the github.dev session and exfiltrates it via api.github.com/user/repos. The victim sees a repository open in what looks like a normal editing session. The token is gone within seconds.
Why the Token Model Is the Real Problem
The four-step chain is clever, but the structural issue is simpler. When a user opens github.dev, GitHub posts an OAuth token to the editor. That token is not scoped to the repository the user opened. It is the full github.dev session credential, carrying read and write access to every repository the account can reach (public, private, and organizational). An attacker who escapes the webview sandbox, by any method, gets the same broad access.
Compare this to GitHub Codespaces, which provisions credentials inside a container-isolated environment with per-session, per-repo scoping. The community reaction on Hacker News flagged this design gap directly: Codespaces isolates by default, while github.dev hands the browser a token that covers the entire account.
The blast radius is the problem. Any future sandbox escape in github.dev’s webview layer, the Jupyter renderer, or the extension host produces the same outcome: full GitHub account compromise. The four features Askar chained are implementation details. The over-scoped token is the architectural constant.
Researcher Credited Microsoft’s Silent-Patch History as Motivation for Full Disclosure
Askar notified GitHub one hour before publishing his writeup, calling it “mainly a courtesy.” He chose full public disclosure because a previously reported VSCode issue was “silently fixed without credit or acknowledgment of its security impact,” according to his account.
He is not the only researcher reaching that conclusion. Abijita.com reports that another researcher using the name “Nightmare Eclipse” has publicly disclosed multiple Microsoft zero-days, citing similar frustration with MSRC. And Microsoft’s Security Response Center has a documented pattern with VSCode specifically: when extensions were previously found capable of reading other extensions’ OAuth tokens, Microsoft called it “an inherent result of their design choice” and declined to fix it. The VS Code security advisories page was empty as of the disclosure date.
What to Do Right Now
As of June 3, 2026, no patch has been confirmed. If you have used github.dev recently, the practical steps are:
- Clear cookies and local storage for
github.devin every browser you use. - Revoke unrecognized OAuth tokens at GitHub Settings → Applications. Remove anything you cannot identify.
- Rotate repository secrets for any repo whose token may have been exposed, especially deployment keys and CI secrets.
- Treat github.dev links from untrusted sources as you would treat any executable download. Do not click them.
- Switch CI/CD automation to GitHub fine-grained personal access tokens, which are scoped to specific repositories, rather than relying on broad OAuth grants.
What This Means for CI Runners and Coding-Agent Sandboxes
The implications extend past individual developers clicking links in a browser. CI pipelines and coding-agent environments that inject GitHub tokens into VSCode-based tooling inherit this exact exposure. Any sandbox that runs VSCode or a VSCode-compatible editor with a GitHub OAuth token, whether for automated code review, AI-assisted editing, or remote development, trusts the same webview layer and the same extension-loading mechanism.
If the token injected into that environment is over-scoped, a vulnerability in any webview component, extension host, or Jupyter renderer produces the same outcome Askar demonstrated: silent exfiltration of a credential that reaches every repository the token can touch. The fix is not to patch individual sandbox escapes. It is to ensure that tokens injected into editor environments are scoped to the minimum set of repositories the automation needs, with the shortest viable lifetime.
Editor vendors, and the platform teams building on top of them, need to treat deep-link handlers, webview message-passing, and extension-loading paths as browser-grade attack surfaces rather than internal plumbing. Askar’s chain works because each of the four features was designed for convenience in a trusted context, and none assumed it would be the last line of defense between untrusted JavaScript and a full-scope OAuth token. That assumption is now public, and the exploit is reproducible.
Frequently Asked Questions
Can I check GitHub audit logs to find out if my token was already stolen?
Look for authenticated API calls to repositories you did not access during the timeframe you used github.dev. The malicious extension exfiltrates tokens by calling api.github.com/user/repos, so that endpoint appearing under your account from an unfamiliar session is a strong signal. Also check GitHub Settings, then Security log, for OAuth authorizations you do not recognize, and review whether any repositories were forked by unfamiliar accounts in the hours after you opened a github.dev link.
How does the github.dev token differ from what third-party OAuth apps receive?
Third-party OAuth apps must request specific permission scopes (repo, read:org, etc.) that the user explicitly approves on an authorization page. The github.dev token skips this consent flow entirely: github.com posts a session credential directly to the editor with no user-visible scoping or approval step. A developer who would deny full repository access to a third-party app receives exactly that level of access in github.dev’s webview layer without being asked.
Are other browser-based editors vulnerable to the same class of attack?
The ingredients are not VSCode-specific. Any browser-based editor that receives a broad credential on load, runs untrusted content in a webview, and forwards keyboard or message events between those contexts carries the same structural risk. The deciding factor is credential scope: an editor that provisions per-repo or per-session tokens limits the damage from any single webview escape, regardless of the editor vendor.
What does the absence of CVEs for VSCode vulnerabilities mean for security teams?
Without assigned CVEs or published advisories, there is no standard mechanism for security teams to determine whether their environment is patched against known VSCode vulnerabilities. Microsoft’s documented practice of silently patching VSCode issues means that fixes may ship in routine updates without any security bulletin, leaving teams unable to correlate a patch with a specific threat. Askar cited this pattern as his reason for full public disclosure with one hour of notice.