github.dev Token Theft Shows Browser IDE Risk

Security researcher Ammar Askar published a June 2, 2026 disclosure describing a github.dev and Visual Studio Code attack path that could expose a GitHub OAuth token after a victim opened a crafted notebook in the browser-based editor. The proof of concept chained notebook webview behavior, synthetic key events, and extension installation behavior to install an attacker-controlled extension that read the token available to github.dev.

Microsoft's public VS Code pull request on June 3 added a trust confirmation before opening notebooks in serverless web sessions and hardened the installExtension command so arbitrary caller-provided context is no longer accepted. That is an important mitigation. The wider lesson is not limited to one fixed web editor bug: browser IDEs and desktop editors now sit close to source code, OAuth tokens, AI coding tools, package managers, and cloud credentials, so extension and token policy have become core supply-chain controls.

Askar's disclosure described a practical attack against github.dev, the lightweight browser-based editor GitHub provides for opening repositories and pull requests. In the documented path, a victim who opened a crafted notebook in github.dev could have JavaScript running inside a notebook webview simulate editor key events, accept an extension recommendation, and trigger installation of a malicious extension. That extension then read the GitHub API token passed into the browser editor and used it to query repositories available to the victim.

The proof of concept matters because the action looks close to normal developer behavior. Opening github.dev links, previewing notebooks, installing editor extensions, and using GitHub-authenticated editor features are routine for many teams. The exploit did not require the victim to paste a token into a phishing page. It abused the way trusted editor actions could be reached from content that should have stayed less trusted.

The most important claim in the disclosure is about token reach. Askar reported that the token available to github.dev was not limited to the single repository the victim had opened. If a token can read or write every repository the user can access, the blast radius follows the user's role rather than the file that triggered the attack. That is a serious difference for maintainers, release engineers, security staff, and employees with broad organization membership.

This is also why OAuth application review matters. GitHub's own documentation explains that OAuth apps can receive read or write access depending on the authorization. GitHub Apps are often preferred for automation because they can use fine-grained permissions and repository selection. For interactive web editors, the same principle applies: the less a token can touch by default, the less an editor bug can expose.

A Microsoft VS Code pull request merged on June 3, 2026 shows the main service-side mitigation. The PR title says notebooks in serverless web sessions now require confirmation, and the installExtension command no longer accepts arbitrary caller-provided install context. In plain terms, the fix adds a human trust gate before the risky browser notebook path and narrows an extension-installation command surface that the exploit chain had used.

SecurityWeek reported on June 5 that Microsoft said the issue had been mitigated for its services and that no customer action was required. That statement should be read narrowly. It addresses Microsoft's hosted service posture after the fix. It does not mean every developer environment is immune to malicious notebooks, untrusted repositories, extension abuse, or overly broad GitHub tokens.

The public reporting and Askar's writeup distinguish between github.dev and desktop VS Code. The browser path was the easier route because github.dev already runs in the browser and can be reached by a link. Askar also wrote that related behavior exists in desktop VS Code, but exploitation there requires more interaction, such as convincing a victim to clone a repository and open a notebook with malicious webview content.

That distinction matters for response. A browser-service mitigation can reduce the one-click github.dev path, but developer workstations still need extension controls, repository trust decisions, local token hygiene, and monitoring. Desktop editors are privileged local applications. An extension or webview that crosses a trust boundary can often reach files, credentials, shells, local services, or source trees in ways that ordinary web content cannot.

Start with high-trust GitHub users: maintainers, organization owners, release engineers, CI administrators, and developers with access to private repositories or package publishing credentials. Review GitHub audit logs for unusual OAuth activity, repository enumeration, clone spikes, token use from unexpected IP ranges, new or unfamiliar extension-related activity, and write operations that do not match normal work. Treat suspicious activity as a token incident, not just a browsing event.

Then review OAuth and extension inventory. Ask users to remove stale GitHub OAuth app authorizations, clear github.dev site data if there is uncertainty about prior exposure, update VS Code and browser-based editor environments, and uninstall extensions that are unused, recently added under pressure, or published by unfamiliar accounts. Enterprise teams should move from informal guidance to explicit extension policy where possible.

The durable control is least privilege at the developer-tool layer. Prefer fine-grained GitHub Apps where applications do not need broad OAuth access. Restrict OAuth app access in organizations. Require SSO enforcement and periodic authorization review. Use short-lived tokens where available, and separate high-risk roles so routine code browsing does not happen under accounts with release or organization-owner privileges.

For editors, use trusted publisher review, extension allowlists for managed fleets, workspace trust, and a clear rule that untrusted repositories and notebooks are opened in disposable environments. The goal is not to ban browser IDEs. The goal is to treat them like identity-bearing systems: useful, connected to sensitive data, and risky when content, extensions, and tokens share too much trust.