The Extensions You Trust Are Reading Everything You Type

You've probably got somewhere between 15 and 40 VS Code extensions installed. Maybe a few JetBrains plugins on top of that. You installed most of them the same way — you needed a feature, someone on Stack Overflow mentioned a plugin, you clicked install, clicked through the permissions prompt without reading it, and moved on.

That workflow is completely normal. It's also a quiet security problem sitting inside your developer environment right now.

This isn't about theoretical risk. Extensions with broad permissions, unclear data practices, and in some cases genuinely malicious intent have been documented in the wild. The VS Code marketplace has had repeated incidents involving extensions that collected credentials, exfiltrated source code, or phoned home with behavioral telemetry. The question isn't whether this is happening — it's whether you know which of your installed extensions might be doing it.

What Permissions Actually Mean

VS Code extensions run in a Node.js environment with access to your file system, your terminal, your network, and your editor content. The permission model is not granular in the way a mobile app's permissions are. An extension that needs to read your open file to provide syntax highlighting has the same baseline access as an extension trying to do something far less benign.

JetBrains plugins operate under a similar model. The IDE plugin ecosystem was built around developer trust — the assumption that extension authors are acting in good faith. That assumption holds most of the time. But most of the time isn't the same as always.

When you install an extension, you're granting it ambient access to whatever you're working on. That includes your API keys if they're in a .env file, your database connection strings, your internal service URLs, and whatever proprietary code your employer considers a trade secret.

Real Incidents, Not Hypotheticals

In 2023, security researchers identified multiple VS Code extensions in the official marketplace that were collecting telemetry far beyond what their stated functionality required — including workspace metadata, file paths, and in some cases file contents. Several of these extensions had hundreds of thousands of installs before the behavior was flagged.

There have also been documented cases of typosquatting in the extension marketplace — malicious extensions published under names nearly identical to popular legitimate ones, designed to catch developers who mistype a search query or click the wrong result. These aren't sophisticated nation-state attacks. They're opportunistic, and they work because developers install extensions quickly and without scrutiny.

AWS credential files, .env files, and SSH keys sitting in a developer's home directory are all within reach of any extension running in that environment. The blast radius of a compromised extension isn't limited to the code you're writing — it potentially includes everything your machine can access.

The Telemetry You Agreed To Without Knowing

Many legitimate, well-intentioned extensions collect telemetry by default. Usage statistics, error reports, feature adoption metrics — this is standard practice in software development and usually disclosed somewhere in the extension documentation. Usually.

The problem is that most developers never read extension documentation. They install, they use, and they don't think about what's being transmitted. For an individual developer working on personal projects, that's a reasonable risk tolerance. For a developer working on a financial platform, a healthcare application, or any system handling sensitive data, it's a different calculation entirely.

Some telemetry is benign. Some of it involves sending editor content to remote servers for AI-assisted features — a practice that's become common enough to deserve serious scrutiny. If your company has data handling obligations under contracts, HIPAA, SOC 2, or any other compliance framework, the extensions your developers use are part of that picture whether your security team knows it or not.

How to Actually Audit Your Extensions

Start with inventory. Pull a list of every installed extension across your development team. In VS Code, code --list-extensions gives you a clean output you can compare across machines. Most teams will discover they have no consistent baseline — developers have installed different combinations of extensions with no documentation or review process.

For each extension, check three things: the publisher's identity and verification status, the extension's marketplace page for any reported issues, and the extension's source code if it's open source. An extension without a public repository and a verified publisher is a yellow flag worth investigating before it stays on your machine.

Review network activity. Tools like Little Snitch on macOS or network monitoring built into your corporate endpoint security solution can show you which processes are making outbound connections and where they're going. An extension that's regularly calling home to an unknown domain while you're working is worth understanding before you shrug and move on.

Check for .env file access. Some extensions legitimately need this for features like auto-completion of environment variable names. Many don't. If an extension has file system access and no obvious reason to read your secrets, that's a conversation worth having.

Building a Team-Wide Extension Policy

The fix here isn't paranoia — it's process. Engineering teams that handle sensitive code or operate under compliance requirements should have an approved extension list, just like they have approved software lists for other tools.

This doesn't have to be bureaucratic. A shared document listing vetted extensions with a lightweight review process for additions is enough to dramatically reduce your exposure. Pair it with a periodic audit — quarterly is reasonable — and you've built a defensible practice without meaningfully slowing anyone down.

For higher-security environments, VS Code's extension recommendations feature and workspace-level extension restrictions let you define what extensions are appropriate for a given project context. It's not perfect, but it's better than the current default, which for most teams is nothing at all.

Your development environment is as much a part of your security surface as your production infrastructure. Start treating it that way.