One Click Can Steal Your GitHub OAuth Token

A Link Click That Hands Over Your Private Repositories

On June 3, 2026, security researcher Ammar Askar published a one-click attack against github.dev, the browser-based version of Visual Studio Code that opens when you press the period key on any GitHub repository. In his words: "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." He reported it to GitHub on June 2 and chose full public disclosure.

After the story ran, Microsoft told reporters the problem was fixed on their side: "This issue has been mitigated for our services and no customer action is required." So the immediate hole is closed. The reason it still matters is the design pattern behind it, which is common far beyond github.dev.

The Core Problem: An Over-Privileged Token

When you open github.dev, GitHub hands the in-browser editor an OAuth token so it can read and write the repository you are looking at. The catch is that this token is not scoped to that one repository. As Askar put it, the token "has full access to every other repo that you have access to." One credential, every repo, read and write, including private ones.

That over-privileged token is the prize. Everything else in the attack is about getting code to run in the right place to read it.

How The One-Click Attack Worked

The attack chained a few separate weaknesses together:

1. A malicious webview. github.dev, like desktop VS Code, lets extensions render custom UI inside webviews. The attacker runs JavaScript inside one of these untrusted webviews.
2. Simulated keystrokes. That JavaScript synthesises keypresses in the main editor window, including Ctrl+Shift+P to open the Command Palette, driving the editor as if the user were typing.
3. A trust-check bypass. Extensions dropped into a workspace's local .vscode/extensions folder were installed without the usual publisher-trust confirmation dialog. The attacker uses this to load an attacker-controlled extension silently.
4. Token theft and enumeration. Once running with the editor's privileges, the extension captures the OAuth token github.dev was handed, then calls the GitHub API to enumerate and read every private repository the victim can access.

The result is that a single click on a crafted link could escalate, with no further prompts, into full programmatic access to a developer's entire GitHub footprint.

Important: This Did Not Affect VS Code Desktop

Microsoft was explicit on this point: "this issue does not affect VS Code Desktop." The attack targeted the browser-hosted github.dev environment and its webview and extension-trust behaviour, not the desktop application you install locally. There is also no CVE identifier published for this issue at the time of writing, and we have seen no confirmation of exploitation in the wild. We are not repeating the "active exploitation" framing that some secondary coverage used, because the primary disclosure does not support it.

Who Should Care

Even though the specific bug is mitigated, the underlying lesson applies to any organisation whose developers hold broadly scoped Git platform tokens:

• Teams that rely on browser-based editors (github.dev, and similar cloud IDEs) for quick edits, where a single compromised session can expose every accessible repository.
• Organisations with large private-repository estates, where one over-privileged token is the difference between one repo leaking and all of them leaking.
• Anyone who installs editor extensions liberally, since extension trust and webview isolation are recurring soft spots in modern editors.

What You Can Actually Do

This class of risk is reduced far more by limiting token blast radius than by chasing any single bug:

• Prefer fine-grained, repository-scoped tokens over classic broad-scope OAuth tokens wherever your tooling supports them, so a stolen credential unlocks one repository, not all of them.
• Review and prune authorised OAuth apps and personal access tokens in your GitHub account settings, and revoke anything you do not recognise or no longer use.
• Be deliberate about editor extensions. Install from known publishers, and treat an editor that silently loads workspace-local extensions as a red flag.
• Enforce least privilege at the organisation level: branch protection, required reviews, and short-lived credentials limit what a single compromised token can change.
• Watch for unusual repository access. Sudden API enumeration of many private repositories from a new client is exactly the signature this attack would leave.

If you want help putting least-privilege access controls and credential hygiene in place across your estate, that is part of our security and compliance service. For another recent infrastructure-level threat worth reading, see our note on the HTTP/2 memory-exhaustion exploit that can crash a web server from a single laptop.

The Takeaway

The github.dev hole is closed, and no action is required for that specific issue. The durable lesson is older and broader: a single token that can read and write everything is a single point of catastrophic failure. Scope your credentials down, prune what you do not use, and treat editor extensions as code you are choosing to run. The narrower your tokens, the less any one clever click can take.

Technical details here are drawn from the researcher's public disclosure and Microsoft's on-record response as reported by The Hacker News. There is no CVE assigned at the time of writing; verify the current status against GitHub's own advisories before acting on it.