GitHub's internal repos were breached. The attacker came in through a poisoned VS Code extension.

GitHub published a security advisory on Wednesday confirming a breach of its internal source-code repositories. The compromise was detected on Monday, May 18, when monitoring flagged unusual activity on an employee device. Initial access came through a malicious Visual Studio Code extension the employee had installed from the Marketplace.

The advisory is short on attacker attribution and long on remediation timeline. GitHub isolated the compromised endpoint, rotated “critical secrets Monday and into Tuesday with the highest-impact credentials prioritized first,” and continues to monitor for follow-on activity. The breach matters beyond the immediate damage because the entry point was a developer tool installed by a GitHub engineer at GitHub itself. If they can be hit through the VS Code Marketplace, anyone can.

What the attacker took

GitHub frames the access narrowly. “The activity involved exfiltration of GitHub-internal repositories only,” the company wrote. The attacker has separately claimed roughly 3,800 repositories were accessed, a number GitHub describes as “directionally consistent with our investigation so far.” That’s a lot.

What’s in those repos matters more than the count. Internal repositories at a company GitHub’s size hold infrastructure code, deployment scripts, build pipelines, and, importantly, support-interaction excerpts that surface customer information. GitHub acknowledged this risk explicitly: “Some internal repositories contain customer information like support interaction excerpts.” The company committed to notifying affected customers through established incident-response channels if and when impact is identified.

What the advisory does not cover, by GitHub’s own confirmation: customer source code stored on GitHub.com, GitHub Enterprise Cloud tenant data, or self-hosted GHES instances. Those run on isolated infrastructure that the breached endpoint did not touch.

The VS Code extension supply chain, again

The infection vector is the part that should worry every developer reading this. A “poisoned VS Code extension published by a third party” was enough, per the advisory, to compromise an engineer at GitHub itself. The company hasn’t named the extension publicly, which means the same package may still be live in the Marketplace under either its original name or a typo-squat variant.

VS Code extensions are a known supply-chain risk. Each one ships JavaScript that runs with the user’s full filesystem and network privileges once activated. Researchers at ReversingLabs and others have flagged dozens of malicious extensions over the last 18 months, including the campaign Ars Technica covered last month that singled out Checkmarx and Bitwarden through similar developer-tooling channels. Microsoft’s review pipeline catches the obvious ones; the more careful attackers ship clean code in the first publish and add the payload in a later update.

There is no per-extension permissions model in VS Code today. Install a linter, and that linter can also read your SSH keys, your shell history, your ~/.aws/credentials, your cloud session cookies, and anything git config knows about. The model is identical to a curl-into-bash install script, except the extension auto-updates and most users never review the diff. That’s the problem.

What’s still unknown

Several questions are open as of the advisory’s publication:

• Which extension. GitHub has not named it. Without that, every developer can’t check whether they’re exposed.
• Who the attacker is. Attribution is absent. The 3,800-repo figure came from the attacker, which suggests external claims via a leak channel, but GitHub didn’t characterize the actor.
• Whether customer data leaked. GitHub says it has “no evidence” of customer impact outside the internal repos but those internal repos contain customer-derived data. The notification clause in the advisory implies customers will hear if specific impact is confirmed.
• How the credentials rotation went. “Highest-impact credentials prioritized first” is the right answer; full coverage takes longer, and the window between detection and full rotation is when secondary compromises happen.

GitHub said it will publish a fuller report once the investigation completes. The April Bitwarden CLI worm and the TanStack postmortem both took multiple weeks to land their final write-ups; expect a similar timeline here.

What this means for you

Audit your editor extensions today. Open the VS Code extensions panel, sort by last-updated, and uninstall anything you don’t actively use. Most of us have too many. For the ones you keep, check the publisher: a verified blue-check publisher is a softer signal than the same publisher having a Marketplace track record. Treat extensions like npm packages, because that’s effectively what they are.

For teams: pin extension versions in .vscode/extensions.json and require code review on changes to that file. If you run a security-sensitive shop, consider running Code in a devcontainer or remote workspace where the extension host can’t reach your real credentials directory. The GitHub incident is the highest-profile reminder yet that the IDE is now part of your software supply chain, and most teams are treating it like a personal-productivity tool.