How a poisoned extension turns a dev box into a source code leak
A VS Code extension sits close to the work that matters. It can read files, inspect the workspace, reach out to services, and sit inside a developer’s normal flow without drawing much attention. If the extension has been trojanised, that access stops being convenience and starts being a delivery channel.
That is why extension-based compromise is so awkward. The installer looks ordinary, the editor still opens, and the machine still behaves like a developer workstation. Meanwhile, the extension can watch what is on disk and what is reachable through the user’s session. For source code repository theft, that is enough.
Marketplace trust ends where extension permissions begin. The presence of an extension in the Visual Studio Code marketplace does not make it harmless. The real question is what the extension can touch once it is installed, and whether those permissions match the work being done. A text editor extension that wants broad file access, network access, or command execution deserves a very close look. If it does not need that reach, it should not have it.
Internal repositories are the real prize. Customer data often gets the attention, but internal code, build notes, and private repository contents can be far easier to steal and far more useful to an attacker. Internal repositories also tend to contain references to credentials, deployment paths, service names, and other scraps that make follow-up access easier. One compromised workstation can expose far more than the machine itself.
What to lock down on the workstation before the next install
The easiest mistake is treating a developer laptop like a throwaway endpoint. It is not. It often holds repository access, cached credentials, SSH keys, package tokens, cloud auth material, and enough path information to make later abuse simple.
Review extension permissions against the work you actually do. If an extension asks for access that sits outside its job, reject it. Code formatting does not need broad repository visibility. A theme does not need network reach. A niche helper tool does not need access to every folder on the box. The smaller the surface, the less useful a poisoned update becomes.
Restrict access to internal repos and isolate build credentials. Keep build tokens and repository tokens separate from day-to-day editor access, and limit what a workstation can reach by default. If an extension or account is compromised, the attacker should land in a narrow space, not in every private repository you have ever mounted. That means short-lived credentials where possible, separate identities for build systems, and tighter access on machines that only need to edit code.
A workstation compromise is rarely dramatic in the moment. It looks like a normal install and a normal login, right up until source code starts leaving in the background. Once that happens, the extension is the least interesting part of the incident.
