One Click in github.dev Could Reach Every Repository the Developer Could.
A malicious link could turn GitHub’s browser-based code editor into a credential-stealing extension host. The victim did not need to download a file, clone a repository or approve a new OAuth application. Opening a prepared notebook in github.dev was enough for a public proof of concept to recover a GitHub token with access to every repository the user could reach.
Security researcher Ammar Askar disclosed the chain on 2 June 2026. Microsoft applied a stopgap fix on 3 June, then merged a more complete change that stopped notebook webviews from forwarding synthetic keyboard events into the main editor. The research does not report malicious exploitation in the wild.
The vulnerability had no CVE at disclosure. Its importance comes from the boundary it crossed: untrusted repository content gained influence over a trusted development environment that already held a broadly scoped GitHub credential.
The token was broader than the repository
GitHub lets a user replace github.com with github.dev to open a repository in a lightweight browser version of Visual Studio Code. GitHub sends an OAuth token to the editor so it can read files, create commits and open pull requests.
Askar found that the token was not limited to the repository the user had opened. It could read and write every repository available to that identity, including private repositories. The feature’s seamless authentication therefore placed a high-value credential inside an application that was also rendering attacker-controlled repository content.
A developer with access to many organisational projects presented a particularly large blast radius. Token theft could expose source code, enable malicious commits and provide a path into build, package and deployment workflows connected to those repositories.
A sandboxed notebook simulated trusted actions
The chain began with JavaScript rendered inside a Jupyter notebook webview. That code was supposed to remain isolated from the main editor. Visual Studio Code forwarded keyboard events from the webview so shortcuts would continue to work while the embedded content had focus.
The untrusted script could generate those events itself. It used a built-in shortcut to accept an extension recommendation, then triggered a custom keybinding from a local workspace extension. That keybinding invoked an installation command with publisher trust skipped. The installed extension could then read the GitHub credential and demonstrate access by enumerating private repositories.
No single step looked like a complete account compromise. The attack emerged from composition: notebook script execution, event forwarding, trusted web workspaces, local extension metadata, an installation command and an over-broad token.
The browser was not the only affected environment
The easiest path targeted github.dev because a link could open the prepared repository directly and the browser editor already received the OAuth token. Askar also demonstrated that the underlying Visual Studio Code behaviour existed on the desktop. Exploitation there required the victim to clone the repository and open the notebook, but a successful chain could reach the more powerful desktop extension environment.
This is why the issue belongs to the software-supply-chain threat model. An IDE is not merely a text editor. It is an authenticated control surface for source code, extensions, package managers, terminals, cloud tools and AI coding assistants.
What development teams should do
- Ensure hosted Visual Studio Code services have received Microsoft’s 3 June mitigations and keep desktop Visual Studio Code current.
- Revoke and replace GitHub credentials if a user opened the public proof of concept or another suspicious github.dev notebook before mitigation.
- Review repository, branch-protection, workflow and package-publishing activity for actions performed with the affected identity.
- Limit repository access for human and automation identities so one stolen token does not reach an entire organisation.
- Treat notebooks, workspace recommendations and local extension metadata from unfamiliar repositories as executable content.
- Use central extension policy and monitor newly installed publishers across managed developer environments.
The final lesson is about delegated authority. github.dev needed a token to feel like GitHub. Visual Studio Code needed rich messaging and extension features to feel like an IDE. The attack connected those conveniences until one click could cross from untrusted content into organisation-wide source-code authority.
Sources: Ammar Askar’s original research and proof of concept (published 2 June 2026; no publication time provided), Visual Studio Code issue and mitigation discussion (opened 2 June 2026; GitHub displays relative event times rather than a stable publication time), and The Hacker News (published 3 June 2026; no publication time provided).
