One-Click VS Code Flaw Exposed GitHub OAuth Tokens to Theft
A researcher-disclosed bug in Microsoft's browser-based VS Code variant let a single crafted link siphon tokens with read/write access to private repos.
Key points
- Researcher Ammar Askar reported a one-click flaw in github.dev, the browser-hosted VS Code GitHub launches when a user presses
.on a repository page. - A single crafted link could steal a GitHub OAuth token scoped to read and write private repositories.
- Microsoft and GitHub have patched the underlying flow; no user action is required on the web infrastructure itself.
- Anyone who clicked suspicious github.dev links during the exposure window should rotate personal access tokens and review authorized OAuth apps.
- No public evidence of in-the-wild exploitation has surfaced.
What was the actual bug?
Askar found an OAuth flow weakness that let a malicious page coerce the editor into surrendering the token meant for legitimate extension auth. One link. No credential prompt, no second click required. Because github.dev runs as an authenticated session tied to the user's GitHub identity, a token leak there reaches everything that scope covers, private repositories included.
We first reported Askar's finding on 3 June 2026 in "One Click in VS Code Was Enough to Hand Over Your GitHub Token", and a follow-on story the next day detailed how an unscoped token and a skipped publisher trust check compounded the exposure.
Why does token scope matter here?
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, or tamper with CI workflows and pivot into downstream package registries through release automation. Supply-chain implications are real, even if no exploitation has been confirmed publicly.
Should you worry about nation-state interest?
This is a capability story, not yet an intent story. There's no attribution, no tracked cluster, no infrastructure overlapping with a known actor. That said, token-theft primitives against developer tooling are exactly the kind of primitive that gets folded into nation-state tradecraft once the fix lands in a public changelog. Groups with documented appetite for developer access, including DPRK-aligned clusters tracked as Jade Sleet by Microsoft and as TraderTraitor by CISA, have run multi-stage campaigns targeting GitHub users. The researcher hasn't published a full proof-of-concept yet, which limits copycat risk for now. Treat that as a window, not a guarantee.
What should security teams do?
Microsoft and GitHub have patched the flow. For teams shipping code through GitHub Actions, the detection surface that matters is the workflow run log: runs initiated from unfamiliar refs, secrets accessed outside normal cadence, and deviations from your usual runner footprint.
Two steps worth prioritising across any affected org: audit OAuth app authorizations and revoke anything stale or unrecognized, and enforce branch protection with required signed commits so a stolen token can't quietly rewrite history.
