Security researcher Ammar Askar published a proof-of-concept exploit on June 2, 2026 demonstrating a zero-day vulnerability in github.dev, the browser-based VS Code environment GitHub serves at github.dev. The attack requires a victim to click a single link. The result is the silent theft of a GitHub OAuth token that grants read and write access to every repository the victim can reach: private or public, across all organisations they belong to.
Microsoft acknowledged the vulnerability and applied a server-side mitigation on the same day. No user-side patch is required. However, the exploit remained viable for approximately 48 hours between the researcher’s publication and Microsoft’s full remediation, and the underlying architectural issue it reveals is worth understanding regardless of the patch status.
How the attack works
When a developer navigates from github.com to the github.dev editor on any repository, GitHub’s infrastructure automatically passes an OAuth token to the browser-based VS Code session. This is by design: the token is what allows the editor to read files, commit code, and interact with pull requests. The critical detail is that this token is not scoped to the specific repository the user opened. It covers every repository the authenticated user can access.
Askar’s exploit uses a crafted Jupyter notebook (.ipynb file) as the delivery mechanism. When a victim opens a link pointing to a github.dev page loading a malicious notebook, the notebook executes a JavaScript payload via an HTML image tag with an onerror handler inside the notebook rendering context. VS Code renders Jupyter notebooks inside a sandboxed webview, but the sandbox contains a deliberate exception: keyboard shortcut events pass through the boundary from inside the webview to the main editor, so that shortcuts keep working while a notebook is open.
Askar’s payload exploits this exception by simulating keypresses through the webview boundary, triggering the Command Palette, and using it to install an attacker-controlled extension from a remote source. The extension reads the OAuth token from the session context and exfiltrates it to an attacker-controlled endpoint. No security warnings appear, no permission prompts fire, and there is no visible indicator that anything unusual has occurred.
What is at stake
The OAuth token github.dev receives is not a narrow, read-only credential. Its scope covers every repository the authenticated user can access, meaning a typical developer’s token would give an attacker full read and write access to their personal repositories, every private repository across every organisation they are a member of, and the ability to read GitHub Actions secrets stored at the repository level.
An attacker with this token can read source code, push commits, create or modify branches, approve pull requests, and interact with the GitHub API as if they were the victim. For organisations where developers work with infrastructure-as-code repositories, internal tooling, or applications that embed configuration in source, the exposure surface from a single stolen token is broad. It is the same class of credential sweep that the Miasma campaign earlier this month used to publish malicious versions of npm packages after compromising a CI pipeline with similarly over-scoped tokens.
The disclosure controversy
Askar did not use Microsoft’s standard Security Response Centre process for this disclosure. He cited a prior incident in which MSRC patched a VS Code vulnerability he had reported without crediting him and publicly classified it as having no security impact. In response, he gave a GitHub security contact approximately one hour of notice before publishing the full exploit and proof-of-concept code.
The resulting discussion in the security community reflects a genuine tension in coordinated disclosure: what notice period is adequate, and what obligations exist when past disclosure experiences have been dismissive? Microsoft’s same-day server-side mitigation demonstrates the company had the technical capacity to respond quickly once the issue was public. Whether that speed would have been applied under a private disclosure process is a separate question.
From a practical perspective, organisations whose developers used github.dev during the window between June 2 and the mitigation should review repository access logs for unusual activity, particularly unexpected commits, branch creations, or API access from unfamiliar IP addresses.
What teams should do
Adopt fine-grained personal access tokens. GitHub’s fine-grained PATs allow token scope to be limited to specific repositories and specific actions. Replacing broad OAuth tokens with repository-scoped, action-scoped PATs means a stolen token has a confined blast radius. This is worth doing regardless of this specific incident.
Review github.dev use in your organisation. If your developers do not actively use the browser-based editor at github.dev, GitHub organisation settings allow you to restrict access to it. Removing an attack surface that the team does not depend on is a straightforward risk reduction step.
Enforce commit signing. Signed commits allow maintainers to verify that commits were made by the holder of a specific signing key rather than just any holder of a valid token. If a stolen OAuth token is used to push commits, a signed-commit enforcement policy provides an additional detection layer.
Monitor organisation audit logs. GitHub’s organisation-level audit log records repository access events, OAuth app authorisations, permission changes, and API interactions. Reviewing this log continuously rather than reactively is the difference between detecting an intrusion early and discovering it months later during an unrelated review.
If your team would like help reviewing your GitHub access control architecture, implementing fine-grained token policies, or setting up audit log monitoring across your repositories, contact Excello Digital. We help engineering teams in Europe design development environments where a single stolen credential cannot put an entire organisation’s codebase at risk.