Security researcher Ammar Askar has publicly released a fully working proof-of-concept (PoC) exploit that can steal a victim's GitHub OAuth token — granting read and write access to every repository they own, including private ones — with nothing more than a single link click. No phishing page. No social engineering beyond "click this." Just a malicious GitHub repository opened in GitHub.
Askar made no attempt to coordinate disclosure with Microsoft's Security Response Center (MSRC). He's done that before, and he says the experience was bad enough that he won't do it again.
The Attack Chain: A Cleverly Chained Exploit
The vulnerability lives inside github.dev, GitHub's browser-based version of Visual Studio Code (VSCode). When a user opens any repository through github.dev, GitHub's servers silently POST an OAuth token to the editor — a token that isn't scoped to just that one repo. It has full access to everything the user can touch on GitHub.
To get that token out, Askar exploited a subtle but significant flaw in how VSCode handles its sandboxed "webviews" — the isolated iframes (inline frames) used to render content like Jupyter notebooks and Markdown previews.
While these iframes run in a separate browser origin to prevent untrusted code from accessing VSCode's internals, VSCode deliberately punches a hole through this boundary so that keyboard shortcuts keep working from inside a webview. When you press a key inside a webview, a did-keydown event gets relayed to the main editor window.
The problem: nothing stops JavaScript running inside a webview from dispatching synthetic keyboard events — events that VSCode's main window treats as genuine user input.
Askar's PoC exploits this with a repo containing a Jupyter notebook and a local workspace extension. The notebook's JavaScript payload waits a few seconds for VSCode to surface a notification prompting extension installation, then fires a simulated Ctrl+Shift+A keystroke to accept it.
The extension — which lives inside .vscode/extensions and bypasses VSCode's publisher trust check because local workspace extensions are considered implicitly trusted — then registers a custom keybinding.
One more simulated keystroke later, a second extension installs silently, retrieves the GitHub OAuth token from the editor's session, queries the GitHub API for private repo names, and displays them in an information box alongside the stolen token.
The entire attack runs in under 30 seconds. A user needs only to open the malicious notebook link.
The vulnerability also affects the desktop version of VSCode, where an attacker would need to convince a target to clone a repo and open the notebook — a higher bar, but still achievable. If there's any other XSS in a desktop VSCode webview, the same technique delivers full remote code execution.
Why He Didn't Tell MSRC First
Askar's disclosure is a direct consequence of accumulated frustration with how Microsoft handles VSCode security reports.
In a previous report, he says MSRC silently patched the issue, gave him no credit, and classified it as having no security impact.
He points to a pattern: a command injection in VSCode's built-in Git extension reported by SonarSource was marked ineligible. A researcher named Justin Steven found an XSS in the built-in Jupyter Notebook extension — also ineligible. MSRC's position, according to Askar, is that even first-party extensions that ship with VSCode are out of scope.
"In the future, I am going with the public disclosure route for any VSCode-related bugs I find," he wrote. "I would encourage other security researchers to do the same until there is some improvement," — Askar wrote in his previous blog post.
This disclosure arrives in the middle of a larger, louder argument about exactly this dynamic. In April and May 2026, a researcher operating as Nightmare Eclipse dropped six Windows zero-day exploits in rapid succession — BlueHammer, RedSun, UnDefend, YellowKey, GreenPlasma, and MiniPlasma — all without coordinating with Microsoft.
Three were exploited in live attacks before patches arrived; CISA added them to its Known Exploited Vulnerabilities catalog.
Microsoft responded by threatening to involve its Digital Crimes Unit, hinting at criminal referrals. The security community largely reacted with dark amusement. Jason Lang, a Team Lead at TrustedSec, called Microsoft's position "hilarious" given the horror stories researchers routinely share about MSRC. Kevin Beaumont, a former Microsoft employee and respected security voice, described the situation as "a dumpster fire of their own making."
It is into this environment that the github.dev token theft PoC landed. The timing is not coincidental.
The Bigger Picture: VSCode Is a High-Value Target
According to the researcher, the GitHub.dev attack surface is particularly sensitive because the OAuth token it issues isn't limited in scope. It isn't a read-only token for one repo — it's a broad credential that can clone private repositories, push commits, alter settings, and trigger workflows across everything a user has access to. In a corporate environment, that can mean access to an entire organization's private codebase.
This arrives weeks after TeamPCP, a financially motivated threat group, breached roughly 3,800 of GitHub's own internal repositories via a poisoned VS Code extension installed on a GitHub employee's device. That breach, confirmed by GitHub in May 2026, underscored how completely the extension ecosystem has become a primary attack surface for credential theft and supply chain intrusion.
VSCode's security team does deserve partial credit: the existing defenses — strict Content Security Policy, DOMPurify-sanitized Markdown rendering, and the script-src 'none' directive in extension views — prevented the attack from becoming considerably worse. Without those controls, the same technique could have enabled one-click remote code execution on every desktop VSCode user who clicked a link.
How to Protect Yourself Right Now
The most effective mitigation Askar identifies is clearing github.dev's local site data from your browser. If you have never completed the initial sign-in flow on github.dev, you'll see a prompt before the editor loads — giving you a chance to navigate away if a link seems suspicious. If you have used github.dev before and haven't cleared your data, that prompt is gone, and the attack can run silently.
In Chrome: Click the lock icon in the address bar → Cookies and site data → Manage on-device site data → delete all data for github.dev and its subdomains.
If you ran Askar's PoC to test your own exposure, uninstall the proof-of-concept extension from your github.dev environment — otherwise it will persist across every github.dev session you open.
There are no CSRF tokens or other protections that limit which links on the internet can redirect you into github.dev. Until Microsoft patches the webview keydown relay behavior and properly scopes the OAuth token issued to github.dev, the attack surface remains open.
The PoC repository and installed extension code are publicly available. Microsoft has not issued a public statement on this disclosure at the time of writing.