GitHub's Browser VSCode Handed Attackers a Skeleton Key to Your Private Repos

Press . on any GitHub repository and the URL flips from github.com to github.dev. Most developers treat this as a convenience trick. In practice, it was also an attack surface.

Researcher Ammar Askar published a writeup this week detailing how the browser-based VSCode instance at github.dev receives an OAuth token posted directly from github.com. That token is not scoped to the repository you opened. It carries full access to every repo your account can touch — public, private, all of it.

The failure mode here is straightforward. An attacker plants a malicious Jupyter notebook in a repository. When a victim opens that notebook inside github.dev, the notebook installs a local workspace extension while bypassing the publisher trust check entirely. The extension grabs the OAuth token, queries the GitHub API for private repository listings, and exfiltrates both. No cloning required. No terminal. Just a browser tab.

Askar told us this was "about as serious as it gets." Any website could redirect a developer to a crafted github.dev link. If you could get a maintainer of a popular open-source project to click, you could commit whatever you wanted to their codebase. Supply chain implications write themselves.

Microsoft applied a stopgap: github.dev now prompts for confirmation before opening notebooks, and commands can no longer skip the trusted publisher requirement. It is a patch. Whether it is the right architectural fix — scoping that OAuth token to the repository that actually triggered the session — is a different question the post-mortem will eventually have to answer.

The disclosure timeline is where this gets messy. Askar gave GitHub one hour of notice before publishing. His reason: a prior VSCode vulnerability he reported was fixed without credit. So this time he didn't extend the usual courtesy window. Microsoft's response landed as pure PR boilerplate about valuing the security research community, which does nothing to address the structural problem he's describing.

The coordinator disclosure model only works when both sides hold up their end. Researchers spend real hours building proof-of-concepts, writing reproduction steps, and sitting on findings while vendors triage. When vendors fix the bug and quietly drop the researcher's name from the advisory, the implicit contract breaks. One-hour notice is the logical response to that, even if it isn't the comfortable one. Enterprises end up exposed in the gap either way.

For platform engineers running GitHub-integrated CI/CD pipelines, the practical exposure here isn't abstract. A stolen token with org-wide repo access is a direct path to poisoned dependencies, backdoored builds, or exfiltrated source. IAM hygiene in Codespaces and github.dev sessions should get the same scrutiny you'd apply to a service account in IAM or Workload Identity Federation.

Operational takeaway: If your threat model includes supply chain attacks, treat every developer browser session touching private repos as a credential issuance event — and audit accordingly.