One-Click VS Code Flaw Exposed GitHub OAuth Tokens to Theft

Microsoft has patched a one-click attack in Visual Studio Code that could hand an attacker a victim's GitHub OAuth token after a single link click.

The bug was reported by researcher Ammar Askar. It affected github.dev, the browser-hosted variant of VS Code that GitHub spins up when a user presses . on a repository page. Because github.dev runs as an authenticated session against the user's GitHub identity, a token leak there is a token leak everywhere that scope reaches — private repositories included.

Askar's writeup describes an OAuth flow weakness that let a malicious page coerce the editor into surrendering the token meant for legitimate extension auth. The attacker-controlled link did the rest. No credential prompt. No second click. Just navigation.

The practical blast radius is what makes this notable. GitHub tokens issued to the web editor carry scopes broad enough to read and write repository contents. An attacker holding one could exfiltrate source, plant a backdoored commit, tamper with CI workflows, or pivot into downstream package registries via release automation. Supply-chain implications are obvious, even if there is no public evidence of in-the-wild exploitation at this point.

This is a capability story, not yet an intent story. There is no attribution here, no tracked cluster, no overlapping infrastructure with a known actor. But token-theft primitives against developer tooling are exactly the kind of bug that gets folded into nation-state tradecraft once it surfaces. Groups with a documented appetite for developer access — including the DPRK-aligned clusters tracked as Jade Sleet by Microsoft and as TraderTraitor by CISA — have run multi-stage campaigns against GitHub users before, including the npm and PyPI poisoning operations attributed across vendor naming conventions.

Microsoft and GitHub have remediated the underlying flow. Users do not need to take direct action on already-patched web infrastructure, though anyone who clicked suspicious github.dev links during the exposure window should consider rotating personal access tokens and reviewing authorized OAuth apps and recent repository events for unexpected pushes.

A few defensive notes worth flagging for security teams:

• Audit OAuth app authorizations across the org and revoke anything stale or unrecognized.
• Enforce branch protection and required signed commits so a stolen token cannot quietly rewrite history.

For organizations that ship code through GitHub Actions, the relevant detection surface is the workflow run log. Look for runs initiated from unfamiliar refs, secrets accessed outside normal cadence, and any deviation from your usual self-hosted runner footprint.

The researcher has not, at time of writing, published a full proof-of-concept, which limits copycat risk in the short term. Treat that as a window, not a guarantee. Token-stealing bugs in developer IDEs tend to get reverse-engineered fast once a fix lands in a public changelog.