VS Code Extension as Entry Point: 3800 Repositories Compromised

When it comes to source code leaks, people usually think of CI/CD vulnerabilities, forgotten SSH keys, or token interception. But a recent GitHub incident is a reminder that the weakest link might be something a developer installs into their IDE in a couple of clicks. Attackers compromised an employee's device through a malicious VS Code extension and gained access to 3800 internal repositories — then tried to sell the data for $50,000. Original story at Tom's Hardware.

The problem isn't VS Code itself — any environment with extensions (IDEs, browser plugins, Slack bots) creates an attack surface that is rarely controlled centrally. Developers tend to trust the extension marketplace, but the review of published plugins is often superficial: obfuscated code, masquerading as popular utilities, auto-updating with package substitution — classic tricks. In the case of the VS Code Marketplace, there is a security audit, but it doesn't guarantee protection against targeted attacks.

Why this isn't an isolated case

Most teams set policies for CI/CD, restrict access to production infrastructure, but the developer's IDE remains a blind spot. The developer decides which extensions to install, often without considering security. And an extension that formats code or highlights syntax gets access to the file system, network, and — critically — environment variables and tokens. If an attacker controls such extensions, they can read source code, modify code on the fly, or steal credentials.

In our experience, in projects where we connect to legacy systems, we often see that access to repositories and production data is not segmented from the developer's local environment. One malicious dependency in package.json or a plugin — and the boundaries are blurred.

What you can do right now

Banning extensions entirely is not a solution — it would reduce productivity. But there are practical steps that lower the risk:

• Internal extension marketplace — publish only vetted plugins, block installation from the public store without approval.

• Environment isolation — run the IDE in a container or VM with minimal privileges, no access to production networks or key stores.

• Extension monitoring — regularly audit installed plugins, check their network activity and updates.

• Minimize tokens — use temporary, short-lived credentials and OAuth with limited scopes.

Of course, even these measures don't provide 100% protection — an extension can access data through obfuscation or a zero-day. But they make an attack significantly more expensive for the attacker.

This incident isn't about VS Code — it's about the fact that developer security must include their tooling. As long as teams ignore this layer, leaks through IDEs will keep happening.