One click on GitHub.dev is all it takes to hand over your private repositories

Researcher publishes proof-of-concept for VS Code flaw that steals unscoped GitHub OAuth tokens via malicious Jupyter notebooks


One click on GitHub.dev is all it takes to hand over your private repositories

Every developer who has ever pressed the period key on a GitHub repository, launching the convenient browser-based VS Code editor known as GitHub.dev, has unknowingly accepted a bargain. In exchange for a lightweight coding environment, GitHub silently passes an OAuth token to the session, one that grants read and write access to every repository the user can reach, not just the repo they opened.

Security researcher Ammar Askar has now shown how a single malicious link can steal that token entirely. The proof-of-concept exploit, published on 2 June 2026, chains together several VS Code behaviours to install a rogue extension inside GitHub.dev, silently exfiltrate the OAuth credential, and enumerate every private repository the victim can access.

Microsoft has acknowledged the flaw and says it is working on a fix. The vulnerability does not affect VS Code Desktop, according to Alexandru Dima, a partner software engineering manager at the company.

How the attack works

The exploit begins with a crafted GitHub.dev link pointing to a repository that contains a malicious Jupyter Notebook file. When the victim clicks, GitHub.com automatically POSTs an OAuth token to the GitHub.dev session. That token is not scoped to the specific repository, it carries full privileges across every repo the user has access to, including private ones.

The 💜 of EU tech

The latest rumblings from the EU tech scene, a story from our wise ol' founder Boris, and some questionable AI art. It's free, every week, in your inbox. Sign up now!

Inside the notebook, a hidden HTML snippet with an onerror handler executes attacker-controlled JavaScript within a sandboxed webview iframe. VS Code uses these webviews to render Markdown previews, edit notebooks, and display other rich content. The critical flaw is that a webview can simulate keyboard events, specifically keydown events, in the main editor window via the postMessage API.

The payload waits a few seconds for VS Code to surface a notification prompting extension installation, then fires a simulated Ctrl+Shift+A keystroke. That shortcut corresponds to the “Accept Notification Primary Action” command, which silently approves the installation of an attacker-controlled extension. The extension then grabs the GitHub OAuth token and calls the GitHub API to list every private repository the victim can access.

Bypassing the trust check

Normally, installing a VS Code extension triggers a publisher trust prompt. But the exploit sidesteps this entirely by using a feature called local workspace extensions. Any extension placed in a repository’s .vscode/extensions folder can be installed without presenting the trust dialogue, because VS Code treats it as part of the workspace rather than a third-party download.

The attacker can also add custom keybindings via the extension’s package.json, mapping arbitrary VS Code commands to keyboard shortcuts. Since the exploit can reliably trigger those shortcuts from the webview, it can chain together virtually any sequence of editor actions. “We can just add a keybind for whatever VS Code command we want, such as installing an extension while skipping the trusted publisher check,” Askar wrote.

Why the researcher went public immediately

Askar did not follow the conventional coordinated-disclosure process. He told The Register that a previous experience with Microsoft’s Security Response Centre soured him on the process. According to Askar, MSRC silently patched a VS Code bug he had reported without crediting him and classified it as having no security impact.

He gave a GitHub security contact roughly an hour’s notice before publishing the full exploit details and proof-of-concept code. The decision echoes a broader pattern of researcher frustration with Microsoft’s vulnerability handling, which recently escalated when the company threatened another security researcher, known as Nightmare Eclipse, with criminal prosecution for publicly disclosing Windows zero-days.

The disclosure also arrives weeks after a separate incident in which hackers breached GitHub itself via a poisoned VS Code extension, stealing approximately 3,800 internal repositories. That attack, attributed to a group tracked as TeamPCP, demonstrated that malicious extensions are not a theoretical risk but an active threat vector in the developer supply chain.

The scope of the risk

The vulnerability is particularly dangerous because GitHub.dev does not implement CSRF tokens, meaning any link on the internet can redirect a user into the attack flow. A single click is sufficient. No additional prompts, no trust dialogues, no visible warnings.

Once the token is exfiltrated, the attacker has the same repository access as the victim. That includes reading proprietary source code, injecting backdoors into private projects, or pivoting to other systems by harvesting secrets stored in configuration files. For developers working on enterprise or open-source infrastructure, the blast radius could be significant.

Recent research has shown that when vulnerabilities in developer tooling are patched quietly, without public advisories or CVE assignments, users on older versions remain exposed without knowing it. Whether Microsoft assigns a CVE to this flaw and publishes a formal advisory will be a test of the lessons learned from those earlier episodes.

What developers should do now

Until Microsoft ships a fix, developers should exercise caution when clicking GitHub.dev links, particularly those pointing to unfamiliar repositories. Reviewing the .vscode/extensions folder of any repository before opening it in the browser-based editor is a sensible precaution, as is auditing OAuth token permissions under GitHub’s personal access token settings.

Organisations that rely on GitHub for proprietary code may want to consider restricting GitHub.dev access until the vulnerability is resolved. GitHub’s own Security Lab, launched to help identify vulnerabilities in open-source code, has not yet commented on the flaw.

The deeper question is architectural. If a browser-based editor receives an unscoped OAuth token by default, and if extensions within a workspace can bypass trust checks, the attack surface is baked into the design. Fixing the specific exploit chain matters, but the growing investment in developer-tool security, such as the recent $18 million Series A raised by API security firm Escape, suggests the industry recognises that the problem runs deeper than any single bug.

Get the TNW newsletter

Get the most important tech news in your inbox each week.

Also tagged with