When your IDE turns on you: lessons from the VS Code extension breach that hit 3,800 repos

For most developers, Visual Studio Code is so deeply embedded in daily work that it barely registers as software anymore. It's just there — the place where the code happens. That familiarity is exactly what makes the latest GitHub incident so unnerving. According to reporting from BleepingComputer, Infosecurity Magazine and others, GitHub has confirmed that roughly 3,800 repositories were compromised through a malicious VS Code extension that quietly siphoned secrets out of developer machines.

This wasn't a zero-day in the editor. It wasn't a clever exploit of GitHub's infrastructure. It was a marketplace extension — installed willingly, granted permissions willingly, trusted willingly. And that's the part Australian dev teams need to sit with.

What actually happened

Based on the public reporting, the attack chain looks depressingly simple. A malicious extension was published to the Visual Studio Code marketplace, where it was installed by developers who assumed it was legitimate tooling. Once running inside the IDE, the extension had the same access the developer did: local files, environment variables, tokens cached on disk, and the privileges of any GitHub session the user happened to be authenticated against.

The result, as confirmed by GitHub and detailed by BleepingComputer, was approximately 3,800 repositories touched by attackers using harvested credentials. Some of those repos were private. Some belonged to organisations. Some were almost certainly considered "low risk" by their owners — side projects, experimental branches, internal tools — right up until someone else got a copy.

Why extensions are the soft underbelly of modern dev

The uncomfortable truth is that a VS Code extension is just a Node.js program running on your laptop with your user privileges. There is no meaningful sandbox between an extension and the rest of your machine. If you've installed something to lint your YAML or pretty-print your JSON, that something can, in principle:

That's not a flaw in VS Code — it's the price of an extensible editor. The same is true of JetBrains plugins, Neovim plugins, browser extensions and npm packages. But VS Code's marketplace is enormous, the publishing bar is low, and "install count" is a notoriously bad proxy for trustworthiness. As Infosecurity Magazine noted in its coverage, the attack worked precisely because the extension looked like the kind of thing a developer would casually install.

The blast radius problem

One detail worth dwelling on: 3,800 repos is a lot, but the number of infected developers was almost certainly much smaller. Each compromised machine became a launchpad. A single developer at a mid-sized company might hold tokens for a dozen private repositories, a CI/CD system, a cloud provider, and a package registry. The Coinfomania write-up frames this neatly — once attackers had GitHub tokens, the repositories fell as a downstream consequence, not as the primary breach.

This is the part that should worry engineering managers more than the headline. The radius of one careless install is no longer "my laptop." It's every system any token on that laptop can talk to. For startups in Sydney or Melbourne running lean, where one senior engineer often holds production credentials across half a dozen services, the math is brutal.

What to audit in your toolchain this week

If you do nothing else after reading this, do these:

1. Inventory your installed extensions

Open VS Code, run code --list-extensions, and actually look at the list. For each one, ask: do I know who publishes this? Have I used it in the last 90 days? If the answer to either is no, uninstall it. Treat extensions the way you'd treat npm dependencies — as code you are choosing to run.

2. Stop storing long-lived tokens on disk

The reason this breach scaled is that GitHub Personal Access Tokens, cloud keys and similar secrets sat unencrypted in predictable locations. Move to short-lived credentials wherever possible: GitHub fine-grained tokens with expiry, AWS SSO instead of static IAM keys, gh auth login's device flow rather than a PAT in a dotfile. If a secret has to exist on disk, put it behind your OS keychain.

3. Use a separate user or container for risky work

Dev Containers, GitHub Codespaces and remote SSH targets all push the execution environment off your primary machine. An extension running inside a container can still do damage, but the damage is bounded by what's mounted in. For people who routinely try unfamiliar tooling — and that's most of us — this is a high-leverage change.

4. Turn on push protection and secret scanning

GitHub now offers secret scanning and push protection on private repos. Enable them at the organisation level. They won't stop a stolen token from being used, but they will catch the inverse problem of secrets being committed and then exfiltrated.

5. Rotate. Rotate. Rotate.

If you've installed VS Code extensions of uncertain provenance in the last year — and again, that's most of us — assume something on your machine has been read. Rotate GitHub PATs, SSH keys, cloud credentials and package registry tokens. It is annoying for half a day and worth it forever.

The bigger pattern: trust by familiarity

Look at the supply chain attacks of the last few years — the event-stream npm package, the SolarWinds compromise, malicious PyPI typosquats, the recent xz utils backdoor — and a pattern keeps emerging. Attackers don't usually break in through the front door. They get themselves invited in by impersonating something familiar, then wait. The VS Code extension that hit those 3,800 repositories is the same playbook in a new wrapper.

The hard lesson, as covered across Infosecurity Magazine and others, is that the IDE itself is now part of your attack surface. We've spent two decades teaching developers to be suspicious of email attachments, USB sticks and dodgy npm installs. The next decade is going to be about teaching the same suspicion of marketplace extensions — the things we used to wave through because they made the editor a little nicer.

For Australian teams: a practical posture

The Australian Cyber Security Centre's Essential Eight already covers a lot of this in principle — application control, restricting admin privileges, patching applications. But "application control" in 2024 has to include extensions, not just executables. If your organisation maintains an approved software list and that list stops at "VS Code," it's incomplete. The marketplace is the supply chain.

For solo developers and small teams, the answer is less about policy and more about habit. Be boring. Install fewer extensions. Read the publisher name. Prefer official extensions from Microsoft, JetBrains, HashiCorp, AWS and the like over a randomly named utility with 12,000 downloads and no GitHub repo behind it. When in doubt, don't install — and certainly don't grant it access to a machine that holds your production keys.

The 3,800 number will fade from the news cycle in a week. The pattern won't. Treat your editor like the privileged process it is, and audit it like one.

Related on Bleen

Sources