Pierluigi Paganini
June 04, 2026
The security researcher Ammar Askar found a new serious zero-day in Visual Studio Code, told a contact at GitHub about it, and published a working exploit one hour later.
“Just by clicking a link, it’s possible for an attacker to steal a GitHub token that can read and write to your repos, including private ones.” reads the report published by the researcher.
No 90-day window, no coordinated disclosure, no MSRC ticket. The researchers just dropped a PoC on the internet, because he’d been through the MSRC process before and decided once was enough.
The vulnerability resides in github.dev, the browser-based VS Code that spins up when you open a GitHub repo in the editor. When github.com hands an OAuth token to github.dev, that token isn’t scoped to the repo you opened. It’s valid for every public and private repo the user can access.
“On any repository you have access to, if you can change the url from github.com to github.dev or you click this little menu item:”
“You’ll be launched into a little light-weight version of VSCode that runs entirely in your browser (I guess that’s one advantage of having your app written with electron).”continues the report.
“This browser instance of VSCode is pretty powerful, you can view all the files in the repo (even if it’s a private one), you can send out pull requests and even make commits. 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.”
An attacker who can modify a repo’s .vscode/extensions.json file can recommend a malicious VS Code extension, and if the target opens the repo via a crafted github.dev link, the attack mostly runs itself.
The most interesting part of the attack is how it bypasses the installation confirmation. Normally, VS Code asks users to approve an extension before installing it. In this case, the attacker hid malicious HTML code inside a Jupyter Notebook. When the notebook is opened, the code runs in the background and automatically triggers the keyboard shortcut that approves the installation prompt. The malicious extension is then installed without the user noticing and can steal OAuth tokens, giving attackers access to the victim’s repositories with no further action required.
Askar was direct about why he skipped responsible disclosure.
“To summarize the last time I interacted with MSRC regarding reporting a VSCode bug, it was a horrible experience where they silently fixed the bug I pointed out without any credit. They also marked it as not having any security impact. As I mentioned in that post, going forward I would be doing full public disclosure for any security bugs I found in VSCode.” wrote Askar. “Taking a look at a recent report by Starlabs on a VSCode XSS bug marked as ineligible and low severity, it doesn’t look like MSRC has gotten any better about VSCode bugs.”
The expert also mentioned a recent Starlabs report on a VS Code XSS bug that MSRC marked as ineligible and low severity, and concluded the situation hadn’t improved.
He made it clear that he doesn’t blame the VS Code team itself. He said the developers probably needed more time to find a solution that balanced security with usability. His criticism was aimed at Microsoft’s security response process (MSRC), not at the engineers building and maintaining VS Code. In his view, publicly disclosing the issue was one of the few ways to push for stronger security improvements.
The comparison to Chaotic Eclipse writes itself. That researcher who has released six zero-days (MiniPlasma, BlueHammer, RedSun, and UnDefend, YellowKey and GreenPlasma) without any advance notice to Microsoft, three of which were confirmed exploited in the wild before patches existed. Their stated motivation involves a broken agreement and being left homeless, which is vague enough to be either dramatic or genuinely grim. Microsoft responded to the sixth release by invoking its Digital Crimes Unit, then quietly walked that back after the public reaction was uniformly negative. Threatening researchers with lawyers tends not to generate goodwill.
What’s actually happening here isn’t a coordination breakdown. It’s a trust bankruptcy. Researchers who find bugs spend real time and skill turning vulnerabilities into working proof-of-concepts. When the company receiving that work silently patches it, strips the credit, and marks it as low-severity, the incentive to keep feeding that process collapses.
“I’m sure the VSCode team would have appreciated a longer heads up on this to come up with solutions. There is legitimately a UI/UX balance here that needs to be struck with the security concerns. To those folks, I am sorry, but this is one of the few levers I have to try to influence MSRC and the security posture of VSCode.” concludes Askar. “Finding and fully developing security bugs into proof-of-concepts like this takes time and effort on the part of security researchers that should not be disrespected or taken for granted.”
Microsoft’s bug bounty program exists partly to avoid exactly this dynamic, but according to some bug bounty hunters, right now it doesn’t seem to be working.
Follow me on Twitter: @securityaffairs and Facebook and Mastodon
(SecurityAffairs – hacking, Microsoft Zero-Day)
