github.dev zero-day – A single wrong click inside GitHub’s browser-based VSCode environment, github.dev, could let a malicious repository load a rogue extension that escapes a webview sandbox and steals GitHub OAuth tokens—granting attackers access that may include write privileges
For a developer. it’s the kind of moment that feels harmless: a click inside github.dev. GitHub’s browser-based version of VSCode. But security researcher Ammar Askar says one wrong repository could expose a GitHub account through a zero-day in the environment—by turning a workspace session into a token-theft trap.
Askar disclosed a vulnerability in github.dev that could expose GitHub OAuth tokens. Those tokens are powerful enough to let attackers access repositories and organizational code that belong to the affected developer. And because the token exposure happens through a flaw in how VSCode webviews behave. the danger isn’t just theoretical—it’s tied to the trusted bridge between GitHub and the editor experience developers use to move quickly from browsing to coding.
The vulnerability hinges on github.dev’s integration. VSCode is a desktop coding tool owned by Microsoft, the same company that owns GitHub. Microsoft has tightly integrated the two. making it easy to open and edit repositories directly from GitHub using GitHub OAuth credentials. In Askar’s account, it’s that trusted integration that makes the chain possible.
The attack begins by tricking a developer into opening a compromised repository using github.dev. Once the repository is loaded, it can serve a malicious extension into the workspace. From there, the issue is rooted in the way the extension communicates with VSCode through a webview.
Askar says the webview bug allowed a malicious extension to escape the sandbox and steal GitHub tokens. With those tokens in hand, an attacker could impersonate the developer. It’s not limited to passive access either: beyond read access. the attacker could also gain write access to repositories available to the affected developer.
That write access matters in practical terms. Askar says it could let an attacker delete codebases, clone private repositories, or push malicious code to production software. For anyone trying to understand how the pieces connect, Askar points to a proof-of-concept he dumped.
The story doesn’t end at “be careful what you click.” Askar also recommends a concrete safeguard: clearing cached data for github.dev. The steps he provides are specific—click Site Settings from your URL bar. click on cookies and site data. then click Delete data. The exact steps depend on the browser. but the goal is the same: remove cached credentials tied to the environment before they can be reused.
Still, the wider worry is timing and trust. Askar’s disclosure timeline says GitHub received an hour’s notice before publication. with Microsoft introducing an initial safeguard on June 3 and following it later that same day with a broader fix. That response reduces immediate risk. but the nature of the bug underlines why developers have started treating browser-based coding tools like everyday infrastructure rather than a convenience.
Authentication tokens sit at the center of that trust. Once they’re valuable enough to steal, every layer between “open a repo” and “run trusted code” becomes part of the security equation.
The current state is a moving target because the mitigation rolled out in stages on June 3. But the underlying lesson Askar’s disclosure points to is already clear: in workflows built for speed. a single click can be the difference between a normal session and an account takeover attempt—powered by stolen OAuth credentials.
GitHub github.dev zero-day OAuth tokens VSCode webviews security researcher Ammar Askar malicious extensions sandbox escape developer security cybersecurity