QWE AI Academy If you’ve ever pressed the period key on a GitHub repo to open github.dev, you need to read the next 600 words. A bug disclosed on June 2 turned that one click into a full account takeover – read and write access to every private repo you can reach, no password, no 2FA prompt, nothing.
This is the 1-click GitHub token stealing via a VSCode bug story that hit the top of Hacker News. Microsoft pushed a server-side fix the very next day. But the underlying token model that made it possible? Still there. Here’s what to actually do about it.
The takeaway, in 30 seconds
Microsoft rolled out a fix on June 3 – one day after disclosure – so the specific exploit chain no longer works on github.dev. A Microsoft spokesperson told The Hacker News: “This issue has been mitigated for our services and no customer action is required.”
That’s the official line. Here’s the honest one: if you opened any sketchy github.dev link in the days before June 3, rotate credentials and revoke OAuth tokens anyway. And the structural problem – github.com automatically POSTing an OAuth token to github.dev that grants full access to every repository the user has access to – wasn’t fixed. It was just made slightly harder to abuse.
Background: why one click was enough
Security researcher Ammar Askar published the disclosure on June 2. The core problem is that github.dev runs nearly the entire VSCode TypeScript codebase in your browser, and to do anything useful it needs an OAuth token from github.com.
That token is the punchline. Per Askar’s write-up, the token is not scoped to the particular repo you interacted with – it has full read/write access to every other repo you can reach. Open one public README on github.dev, and the browser tab is holding the keys to your private monorepo three orgs away.
The attack chain was clever but boring in the way most exploit chains are: a malicious Jupyter notebook fires synthetic Ctrl+Shift+A keystrokes that VSCode accepts as legitimate input to dismiss the workspace extension install prompt, then Ctrl+F1 triggers a custom keybinding that exfiltrates the OAuth token. No malware, no phishing page. Just a link.
Method A vs Method B: which protection should you actually use?
Most articles tell you to clear your github.dev cookies and call it a day. That’s one option. There’s a better one. Honest comparison:
| Protection | What it does | What it doesn’t do | When to use |
|---|---|---|---|
| A: Clear github.dev cookies + local storage | Forces the consent dialog to reappear when you next visit github.dev, giving you a chance to bail on suspicious links | Doesn’t shrink token scope. Doesn’t help on desktop VSCode. Useless once you click “allow” again. | Right now, as a one-time hygiene step |
| B: Move automation off the github.dev session entirely (fine-grained PATs) | Caps the blast radius forever – a compromised token can only touch the repos you scoped it to | Doesn’t protect your browser session itself; you still need Method A for that | For any script, CI job, or local git operation that currently uses a classic PAT |
Method A is a Band-Aid. Method B is a structural fix. You want both, but if you only do one, do B – it survives the next github.dev bug, and there will be a next one.
Which raises a quieter question: why did this token design ship in the first place? An account-wide OAuth token handed to a browser-based editor – because the alternative (scoped, per-repo tokens) would have required more engineering. That tradeoff is now everyone’s problem.
Walkthrough: lock down your account in under 10 minutes
Here’s the order I’d actually do these in, sorted by impact-per-minute.
Step 1 – Revoke any OAuth tokens you don’t recognize (2 min)
Go to GitHub → Settings → Applications → Authorized OAuth Apps. Anything you don’t remember authorizing in the last year, kill it. While you’re there, check Personal access tokens (classic) – delete anything that looks unfamiliar or broader than it needs to be.
Step 2 – Clear github.dev site data (1 min)
In Chrome: click the lock icon in the URL bar while on github.dev → Cookies and site data → Manage on-device site data → delete everything for github.dev. Per BleepingComputer’s write-up, next time you click a github.dev link, you’ll get a “The extension ‘GitHub Repositories’ wants to sign in using GitHub” warning – that’s the gate that blocks the exploit flow.
Step 3 – Replace classic PATs with fine-grained ones (5 min)
This is the one that pays dividends long after this specific bug is forgotten. Go to github.com/settings/personal-access-tokens and create a fine-grained token. The official docs recommend fine-grained tokens over classic PATs whenever possible – and the reason is concrete.
Fine-grained PATs draw from a set of over 50 granular permissions, each on a “no access”, “read”, or “read and write” basis (per GitHub’s announcement post). You can create a PAT that reads issues and does nothing else – not even read repo contents. A classic PAT stolen the same way this OAuth token was would be full game over. A fine-grained PAT leaks one repo’s issues and nothing else.
Pro tip: Name tokens after where they’re deployed (
ci-deploy-staging-2026), not what they do. When something leaks, you’ll know exactly which machine to disinfect – not stare at three tokens all called “my-token” wondering which one.
Step 4 – Audit your installed VSCode extensions (2 min)
Open VSCode, hit Ctrl+Shift+X, and scan the list. Anything you don’t recognize, uninstall. Pay special attention to anything inside .vscode/extensions/ in a repo you cloned recently – that’s the exact directory the exploit dropped its payload into.
Edge cases the headlines didn’t cover
This is where the story gets uncomfortable.
The desktop VSCode side is messier. The attack also works against the desktop version of VSCode – harder to trigger, but the stakes are higher: this variant can lead to remote code execution on the victim’s device, not just token theft. SecurityWeek reported the desktop version appears to remain unpatched as of the June 3 fix. Microsoft’s “no customer action required” statement applies narrowly to github.dev. Desktop is a different story.
The cookie-clearing trick has a footnote. Askar’s blog puts it directly: “if you’ve ever been past that dialog on github.dev and haven’t cleared your browser’s local storage, you’re completely screwed.” The warning only works if you actually wipe the data first. Assuming “it’ll prompt me anyway” is exactly wrong.
Fine-grained PATs won’t save your browser session. They protect scripts and CI jobs. The github.dev OAuth token is separate machinery – PATs can’t touch it. Method B is a partial fix by design, not a gap in the advice.
The disclosure timeline isn’t gossip – it’s a planning input. Askar notified GitHub one hour before going public. The reason, per BleepingComputer: a prior VSCode bug Askar reported was silently patched by Microsoft without credit or acknowledgment of the security impact. If your organization counts on responsible-disclosure windows to prepare before exploits go public, this case is a reminder that researchers sometimes skip the queue – and they often have good reasons.
The real question nobody is answering
Why does github.dev need an account-wide token to edit one repo?
It doesn’t. The top comment in the Hacker News thread made exactly this point: in a better design, the in-browser editor launches with a temporary per-repo token scoped only to pull and push for the repo in question – no full github.com session at all. If you want the broader GitHub web experience, go back to github.com. Make github.dev a single-repo tool.
Until GitHub does that, every github.dev bug is automatically a full-account-compromise bug. This one’s patched. The class isn’t.
FAQ
I clicked a weird github.dev link last week. Am I compromised?
Probably not – but act as if yes. Revoke OAuth authorizations you don’t recognize, rotate any secrets that might have been sitting in your private repos, and check your repo activity log for unexpected commits or new SSH keys added.
Does this affect GitHub Codespaces too?
No. Codespaces uses a different credential model – isolated per session rather than a shared account-wide OAuth token. The attack surface here is specific to how github.dev handles authentication.
Why didn’t Microsoft assign this a CVE?
They haven’t, as of Askar’s disclosure. His prior experience with MSRC – a reported VSCode bug silently fixed without credit – explains why he went straight to public disclosure this time. For tracking, use the blog post URL rather than a CVE ID, because there isn’t one yet.
Do this next: Open a new tab, go to github.com/settings/security-log, and scroll through the last 30 days. If you see authorization grants or OAuth events you don’t remember initiating, that’s your starting point.