One VSCode Extension, 3,800 Private Repos Gone: Your IDE Is the New Supply Chain

You install VSCode extensions without thinking. So does every developer at your company. This week, security researchers confirmed what a lot of us have quietly worried about: one click on the wrong extension dumped 3,800 private GitHub repositories to an attacker. The intrusion started and ended on a single laptop.

What actually happened

The mechanics are almost insultingly simple. An attacker published a legitimate-looking extension to the VSCode Marketplace. One developer installed it. Game over.

Here’s the part most people underestimate: VSCode extensions run with the same privileges as the developer. They can read the file system, spawn terminal processes, and inspect environment variables. That means GitHub Personal Access Tokens, SSH keys, AWS credentials in ~/.aws, and every secret stashed in a .env file are all sitting in plain sight from inside the extension’s runtime.

The attacker scraped them, authenticated to GitHub as the victim, and cloned every repository that identity could reach. The blast radius: 3,800 internal repos from one laptop.

Why IDEs beat npm as a target

Supply chain attacks used to mean typosquatted npm packages or poisoned PyPI uploads. Editor extensions are a better hunting ground, and attackers have figured it out.

The review bar is low. The VSCode Marketplace, like npm, lets anyone publish. Microsoft runs automated scans, but there’s no meaningful human review for the long tail of extensions with under 10,000 installs.

The execution window is enormous. An npm package runs during install or at runtime. An extension runs continuously, every minute you have your editor open, while your credentials are decrypted in memory and your shell is authenticated. It’s a persistent foothold disguised as a productivity tool.

The credentials are concentrated. Developer laptops are credential warehouses: GitHub tokens, cloud CLI sessions, kubeconfig files, signing keys. Compromise one engineer and you inherit the union of everything they can touch. That’s how a single laptop yielded 3,800 repos.

The defenses that actually work

The takeaway from the security community on Hacker News and X has been consistent: treat extensions as code, not as features. You’d never npm install a random package from an unknown author into production. Stop doing it in your editor.

Practical moves you can make this week:

• Vet before you install. Check whether the extension has a public GitHub repo, when it was last updated, and whether the requested permissions match what it claims to do. A markdown previewer doesn’t need shell access.
• Stop relying on long-lived tokens. GitHub’s fine-grained PATs and OIDC-based short-lived credentials limit the damage when (not if) a laptop is compromised. A token that expires in an hour is worth far less to an attacker than one that lasts a year.
• Run a curated internal registry. For teams above a certain size, an allowlist of approved extensions delivered through enterprise policy beats trusting individual judgment 200 times over.

GitHub already supports push protection and secret scanning. Turn them on. They wouldn’t have stopped this attack, but they shorten the window between compromise and discovery from months to hours.

The cost of casual trust

What makes this incident unsettling isn’t sophistication. It’s the opposite. No zero-day, no clever exploit chain, no nation-state tooling. Just a marketplace, a click, and a developer who assumed the sidebar icon was harmless.

Open your Extensions panel. Count how many are installed. Now count how many you’ve actually vetted past the star rating. That gap is your real attack surface.