- A VS Code zero-day lets attackers steal GitHub OAuth tokens by tricking users into clicking a single malicious link.
- The VS Code zero-day has no patch yet — but users can mitigate the risk by clearing github.dev browser cookies now.
- Researcher Ammar Askar chose immediate public disclosure after a prior bad experience with Microsoft’s security response process.
- The unscoped OAuth token exposed by this flaw grants access to every private GitHub repository the victim can reach.
- A VS Code zero-day lets attackers steal GitHub OAuth tokens by tricking users into clicking a single malicious link.
- The VS Code zero-day has no patch yet — but users can mitigate the risk by clearing github.dev browser cookies now.
- Researcher Ammar Askar chose immediate public disclosure after a prior bad experience with Microsoft’s security response process.
- The unscoped OAuth token exposed by this flaw grants access to every private GitHub repository the victim can reach.
The VS Code Zero-Day That Puts Your GitHub Repos at Risk
A newly disclosed VS Code zero-day vulnerability gives attackers the ability to steal GitHub authentication tokens with nothing more than a single click from an unsuspecting developer. Security researcher Ammar Askar published both a detailed write-up and a working proof-of-concept exploit on Tuesday, and as of now, Microsoft has issued no patch. If you use VS Code and interact with GitHub repositories, this one demands your attention.
The attack hinges on github.dev — the browser-based version of Visual Studio Code that Microsoft operates to let developers browse and edit GitHub repositories directly in their browser. When you navigate from github.com to github.dev, an OAuth token gets passed over via a POST request. That token isn’t scoped to the specific repository you’re working in. It has broad access — potentially to every private repo you can touch.
Askar’s exploit abuses VS Code’s sandboxed webview message-passing system. In plain terms: VS Code uses embedded web views to display certain content inside the editor, and these views can communicate with the main editor process through a message-passing interface. The problem is that this interface can be weaponized. By running malicious JavaScript inside one of these webviews, an attacker can simulate keystrokes in the main editor — effectively pretending to be the user — and silently install a malicious extension that hoovers up the GitHub OAuth token the moment it arrives.
As Askar put it in his blog post:
“This functionality is achieved by github.com POSTing over an OAuth token to github.dev that allows it to interact with GitHub on your behalf. The token is not scoped to the particular repo you interacted with, meaning it has full access to every other repo that you have access to.”
The malicious extension then turns around and hits the GitHub API directly, enumerating every private repository the victim has access to. From a developer’s perspective, this is a worst-case scenario. Private code, internal tooling, unreleased projects — all potentially exposed because someone clicked a link.
How the Exploit Actually Works
To understand why this VS Code zero-day is particularly nasty, you need to understand the trust model VS Code places on its webviews. Extensions in VS Code run with significant privilege, and the message-passing bridge between webviews and the main editor process was designed for flexibility — not adversarial use. That’s a tradeoff that’s coming back to bite Microsoft here.
The attack chain Askar documented is surprisingly compact. A victim clicks a crafted link. The link triggers github.dev to open in the browser. A malicious webview running inside the VS Code environment executes JavaScript that simulates user input — keypresses, specifically — to trigger VS Code’s extension installation flow. The rogue extension installs, captures the incoming OAuth token, and queries the GitHub API. All of this happens faster than any reasonable user could notice something was wrong.
What makes it worse is the breadth of the token. OAuth tokens scoped to a specific resource are a well-established best practice in identity security. The fact that github.dev receives an unscoped token — one that effectively acts as a skeleton key for every repository the user can access — is a design-level problem that sits underneath the VS Code zero-day itself. Even if Microsoft patches the webview exploit tomorrow, the token scoping issue is worth a separate conversation.
No CVE, No Patch — Here’s What You Can Do Right Now
Microsoft hasn’t assigned a CVE ID to this VS Code zero-day yet, and there’s no official fix in sight. That doesn’t mean you’re helpless. Askar outlines a practical mitigation: clear your cookies and local site data for github.dev in your browser. In Chrome-based browsers, click the settings icon in the address bar when on github.dev, then navigate to Cookies and site data > Manage on-device site data and remove the stored data.
Why does this help? Because without the stored session data, the next time anything tries to interact with github.dev on your behalf, you’ll see a prompt: “The extension ‘GitHub Repositories’ wants to sign in using GitHub.” That warning is your cue that something’s trying to authenticate. It won’t stop a determined attacker forever, but it transforms a silent one-click compromise into a visible permission request — which is a meaningful improvement.
The broader lesson here is one the security community has been hammering for years: authentication tokens with excessive scope are a liability. A compromised token that can only read one repo is painful. A compromised token that can read every repo you’ve ever touched is a disaster. Source: https://www.bleepingcomputer.com/news/security/vs-code-zero-day-lets-hackers-steal-github-tokens-in-one-click/
