“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,” Ammar Askar wrote.
The Visual Studio Code chain: how the exploit works
Askar published a proof-of-concept (PoC) that strings together several features and behaviors in Visual Studio Code (VS Code) and github.dev to steal OAuth tokens and then read and write public and private GitHub repositories. The attack requires an attacker to be able to modify a repo’s .vscode/extensions.json file to recommend an attacker-controlled extension for a browser-based VS Code instance launched from github.dev.
Crucially, Askar says github.com passes an OAuth token to github.dev that is not limited to the repository that launched the browser session. If a victim has access to other repos, that token can be used to access those repos as well. The attack path relies on getting the target to open a github.dev link that points to a Jupyter Notebook (an ipynb file). VS Code opens the notebook inside a Webview, and the notebook contains a hidden HTML snippet in a Markdown cell that allows attacker-controlled JavaScript to run inside that Webview.
The JavaScript simulates a keyboard shortcut that VS Code propagates to the main editor, causing the system to automatically accept the extension-installation pop-up that would otherwise alert the user. Once the attacker-controlled extension is installed and running with browser-environment access, it steals the OAuth token and can use it to read and change any public or private repository the token-holder can access.
Ammar Askar’s disclosure choice and timeline
Askar says that negative past experiences with the Microsoft Security Response Center (MSRC) influenced his decision to bypass a conventional responsible-disclosure timeline. He told an “old contact” at the open source platform about the issue and published the PoC roughly an hour after that tip-off.
Askar explained his motivation in the post, citing a previous interaction where MSRC “silently fixed the bug I pointed out without any credit” and had marked it “as not having any security impact.” He also referenced a recent report by Starlabs on a VS Code XSS bug that was marked as ineligible and low severity, arguing this showed MSRC “hasn’t gotten any better about VSCode bugs.” Askar wrote that he would be doing “full public disclosure” for future VS Code bugs and said the public disclosure was one of the few levers he had “to try to influence MSRC and the security posture of VSCode.”
Who is exposed: github.dev users and repository owners
According to the PoC described by Askar, the flaw affects anyone who has ever used github.dev — the feature that opens a GitHub repository in a browser-based version of VS Code. Because the OAuth token passed to github.dev is not limited to the repo that spawned the session, an attacker who can cause a victim to open a repo they control (or have compromised) at a specific ipynb file can potentially exfiltrate tokens that provide broader access to other repos the victim can reach.
The initial precondition — the ability to modify a repo’s .vscode/extensions.json so that github.dev recommends the attacker-controlled extension — means the attack is feasible using repos an attacker already controls or has separately compromised.
Echoes of recent zero-day disclosures: the 'Nightmare Eclipse' parallel
The Register draws a parallel between Askar’s approach and that of a researcher calling themselves Nightmare Eclipse, described as a suspected former Microsoft employee who has been releasing zero-days without prior notice to Microsoft. The source says Nightmare Eclipse has released six zero-days, three of which were quickly confirmed to be exploited in the wild. The researcher’s stated motivation included vague claims about being “stabbed in the back” and being left homeless after an agreement that was not honored.
Microsoft’s initial public posture toward Nightmare Eclipse reportedly included a vague threat involving its Digital Crimes Unit — an action the source says Microsoft quickly backed away from after an outpouring of negative responses.
What this means for developers, security teams, and end users
- Developers and repository maintainers: review who can modify repository files such as .vscode/extensions.json and be aware that recommending extensions in a repo can be weaponized if the repo or its content (for example, an ipynb file) is used to lure users into github.dev sessions.
- Security teams and incident responders: prioritize monitoring of OAuth token use and suspicious extension installations originating from browser-based VS Code sessions; understand that tokens passed to github.dev may not be scoped to a single repo and could be used to pivot to other accessible repositories.
- End users of github.dev: exercise caution opening unfamiliar repos or ipynb files in browser-based VS Code instances and be mindful that pop-ups prompting extension installation may be automated by in-page content according to Askar’s PoC narrative.
The Register reached out to Microsoft for more information; the story notes only that Microsoft was approached. Askar said he regretted not giving a longer heads-up to the VS Code team but framed public disclosure as a response to what he described as disrespectful handling of researchers’ work. The episode underscores a recurring tension: when researchers believe reporting channels fail them, they may choose immediate public disclosure — and when critical tokens are shared across linked browser experiences, that disclosure can quickly translate into a tangible, exploitable chain.
