Developers open GitHub repositories in a browser every day. Hit the period key. GitHub.dev loads. A lightweight VS Code experience appears. Convenience comes at a price. GitHub silently sends an OAuth token with broad permissions. That token grants read and write access to every repository the user can reach. Not just the one opened. Security researcher Ammar Askar demonstrated last week how a single malicious link can steal it all.
The attack surfaced on June 2, 2026. Askar published a detailed blog post and a working proof of concept. His write-up lays out the chain with precision. It exploits the way VS Code handles webviews in the browser-based editor. A crafted Jupyter notebook triggers hidden JavaScript. That code runs inside a sandboxed iframe yet manages to simulate keyboard events in the main window. The result? Silent installation of a malicious extension that grabs the token and enumerates private repositories.
But why does this work? Webviews in VS Code use iframes from a different origin. They communicate with the main editor through postMessage. The system listens for keydown events. Those events bubble up. An attacker can dispatch synthetic Ctrl+Shift+A to accept an extension recommendation notification. Then another keystroke triggers a custom keybinding. The binding calls a command to install an extension from the workspace folder while skipping the trusted publisher check.
Local workspace extensions make the bypass possible. Place files in a repository’s .vscode/extensions directory. VS Code treats them as trusted. No extra prompts. The feature, introduced to support workspace-specific tools, assumes the repository content is safe. On github.dev that assumption fails. The entire workspace loads as trusted by design.
Askar’s PoC puts it together neatly. The notebook contains an image with an onerror handler. That handler runs JavaScript after a delay. It fires the keystrokes. The extension installs. It reads the GitHub token passed to the session. Then it queries the API for all accessible repositories. “Just by clicking a link, it’s possible for an attacker to steal a GitHub token that can read and write to your repos, including private ones,” Askar wrote. The token carries no repository-specific scoping.
Desktop VS Code stays unaffected in the one-click form. It requires the user to clone the malicious repository first. Yet the underlying webview behavior exists there too. GitHub.dev simply removes friction. No CSRF protection on the editor links compounds the risk. Any site can redirect users into the flow.
This disclosure skipped the usual responsible process. Askar gave GitHub security contacts about an hour’s notice. He cited past experiences with Microsoft’s Security Response Center. In one earlier case a VS Code bug he reported received a silent patch. No credit. Rated as low impact. Frustration with that pattern led to immediate publication. Microsoft acknowledged the issue quickly. A partner software engineering manager, Alexandru Dima, confirmed the desktop version remains safe. The company pushed a stopgap fix within a day. It added a confirmation prompt for notebooks and blocked skipping the trust check via commands. A fuller patch followed, preventing keydown events from bubbling in notebook webviews.
The timing carries extra weight. Only weeks earlier GitHub disclosed its own breach. Attackers used a poisoned VS Code extension on an employee’s machine. They pulled data from roughly 3,800 internal repositories. The group known as TeamPCP listed the material for sale. That incident, covered by Varonis and others, showed malicious extensions already serve as a real supply-chain vector. Now a browser-based flaw lets attackers push their own extensions without the victim installing anything from the marketplace.
Tokens like these open doors. An attacker gains the victim’s full GitHub permissions. They can read proprietary source code. They can push changes. They can hunt for secrets in configuration files or environment variables. For organizations with sensitive infrastructure or intellectual property the exposure runs deep. Enterprises that encourage GitHub.dev for quick edits now face new questions about default token behavior.
Microsoft has not yet assigned a CVE. Past episodes where developer-tool flaws received quiet patches left users on older versions exposed without awareness. The Next Web reported on the flaw hours after disclosure and noted the pattern. Whether this case receives a formal advisory will signal if lessons stuck.
Developers hold some immediate defenses. Clear browser cookies and site data for github.dev. Avoid opening unfamiliar repositories in the web editor. Inspect any .vscode folder before proceeding. Organizations can restrict github.dev access through enterprise policies until the dust settles. Auditing OAuth permissions on personal access tokens offers another layer. Yet these steps treat symptoms.
The architectural roots run deeper. Browser-based editors promise speed and zero setup. They inherit the full complexity of VS Code’s extension model and web security boundaries. Webviews provide isolation yet must support rich interaction. Keyboard simulation aids usability. Local workspace extensions reduce friction for legitimate teams. Combine them with an unscoped token passed automatically and the attack surface appears by design.
Recent supply-chain attacks against extensions add pressure. The Nx Console compromise earlier in 2026 reached millions of installs before quick removal. It pulled secrets across multiple clouds and services. GitHub’s breach followed. Each case highlights how developer tools sit at the center of modern software creation. Compromise there radiates outward fast.
Askar’s choice to publish immediately sparked debate on disclosure norms. Some praise the pressure it applies. Others worry about rushed exploits in the wild. Microsoft moved faster this time. The stopgap and subsequent patch arrived the same day the story spread. Still, the episode underscores ongoing tension between researchers and large vendors over credit, timelines and severity assessments.
For now the fix sits in recent VS Code builds. Users of github.dev benefit automatically when they reload. Yet the broader conversation continues. How should token scoping work in web editors? When does a workspace extension deserve implicit trust? Can webview isolation prevent keystroke forgery without breaking features? These questions extend beyond one bug.
Industry attention has sharpened on developer security. Teams now scrutinize extensions more closely. Platform providers face calls for stronger sandboxing and default scoping. The GitHub.dev incident, simple in execution yet broad in consequence, provides a clear case study. One click. Full repository access. The bar for such attacks keeps lowering.
WebProNews is an iEntry Publication