How to Audit Your VS Code Extensions for Security
The GitHub breach happened through a VS Code extension. Here's how to check what you have installed and reduce your exposure in 10 minutes.
On this page
Introduction
In May 2026, a compromised version of the Nx Console VS Code extension was live on the official marketplace for 18 minutes. One GitHub employee installed it during that window. The result: 3,800 internal repositories exfiltrated, plus tokens for GitHub, npm, AWS, and cloud credential stores collected silently before the malicious version was pulled.
If you use VS Code, this matters to you. Not because you are a target — but because the same trust model you rely on every day was the attack surface. This guide walks through exactly what to do right now.
Step-by-Step Guide
Why Extensions Are More Dangerous Than They Look
VS Code extensions are not sandboxed. When you install one, it runs with the same permissions as VS Code itself:
- It can read every file in your open workspace, including
.env.localand any credential file. - It can access environment variables set in your shell session.
- It can spawn processes and make outbound network requests — silently.
- A verified publisher badge proves domain ownership, not that every update pushed under that account is safe.
See Everything You Have Installed
Open a terminal and run this command. It prints every installed extension in publisher.extensionname format:
- Count them. If you have more than 20, you almost certainly have some you no longer use.
- Extensions installed once for a specific project, forgotten tutorial plugins, or tools that haven't been updated in two years — they are all running.
- Unused extensions are pure attack surface with zero upside. Uninstall them.
code --list-extensionsThree Things to Check on Each Extension
For every extension you actively use, spend 60 seconds checking these three things:
- Verified publisher badge. Look for the blue checkmark next to the publisher name in the marketplace. This means the publisher verified domain ownership and maintained good standing for at least six months. Extensions without it deserve more scrutiny.
- Last update date. An extension that hasn't been updated in over a year is unlikely to receive a security patch if a vulnerability is found. If it's also not open-source, you have no way to audit it. Evaluate whether you still need it.
- The GitHub repository. Most legitimate extensions link to a public repo from their marketplace page. Click it. Check whether issues are being responded to, whether the last commit is recent, and whether the codebase looks actively maintained.
Reduce Your Attack Surface
You cannot disable auto-updates entirely without breaking security patches, but you can limit what extensions can reach:
- Enable extensions per-workspace. VS Code lets you enable an extension only for specific workspaces. If an extension is only needed for one project, set it that way. It won't run in other projects and can't touch those credentials.
- Use a separate VS Code profile for sensitive work. Profiles let you maintain different extension sets for different contexts — a general dev profile and a locked-down profile for anything involving production secrets or client code.
- Keep `.env` files out of VS Code workspaces where possible. When you open a folder, every extension can see all files in it. Use a secrets manager or set variables in your deployment platform's dashboard instead of keeping them in local files.
What to Do If You're Concerned
If you had Nx Console installed between approximately 12:30 and 12:50 UTC on May 18, 2026, treat your credentials as compromised. The same logic applies to any extension you aren't certain about:
- Rotate immediately: GitHub personal access tokens, npm publish tokens, AWS access keys — in that order of priority.
- Check your GitHub security log under
Settings > Security logfor any unexpected actions in the 48 hours after any suspicious install. - Revoke and regenerate any API keys your machine had access to, starting with the highest-privilege ones.
- If you use 1Password, Bitwarden, or any other password manager with a VS Code integration — rotate the master credential or access token for that integration.
A Quarterly Audit Habit
This is not a one-time fix. New extensions get compromised. Maintainers abandon projects. Add a recurring calendar reminder for every three months and work through this checklist:
- Run
code --list-extensionsand remove anything you haven't used since the last audit - Check that actively-used extensions still have a verified publisher badge and recent commits
- Review which extensions are enabled globally versus workspace-only
- Confirm your most critical credentials (GitHub, npm, AWS) have been rotated within the last 90 days
Frequently Asked Questions
- How do I know if I was affected by the May 2026 Nx Console breach?
- If you had the Nx Console extension (
nrwl.angular-console) installed and VS Code's auto-update ran between approximately 12:30 and 12:50 UTC on May 18, 2026, treat any credentials on that machine as compromised. Check your GitHub security log for unexpected activity, and rotate GitHub tokens, npm tokens, AWS keys, and any other credentials that machine had access to. - Are VS Code extensions sandboxed at all?
- No. VS Code extensions run in a Node.js process with full access to your file system, environment variables, and network. This is by design — many legitimate extensions need these capabilities to work. There is no permission model that restricts what an extension can read or write. This is a fundamental architectural decision that makes VS Code extensions powerful and dangerous at the same time.
- Does a verified publisher badge mean an extension is safe?
- It means the publisher verified domain ownership and has maintained good standing. It does not mean every update they push is safe. The Nx Console breach happened through a verified publisher whose account token was stolen. A badge reduces risk but does not eliminate it. Treat it as one signal among several, not a guarantee.
- Can I disable VS Code extension auto-updates?
- Yes. Go to Settings and search
Extensions: Auto Update, then set it to false. However, this means you also won't automatically receive legitimate security patches. A more practical approach is to use workspace-level extension enabling so that most extensions are off by default and only active when needed, reducing the blast radius of any malicious update. - Are open-source extensions safer?
- Meaningfully, yes. With an open-source extension, you can audit the code before installing or updating, and the community is more likely to catch a malicious commit quickly. Closed-source extensions are a black box — you have no visibility into what they do. When choosing between two extensions with similar functionality, prefer the one with a public, actively-maintained repository.
VS Code extension security is not about paranoia. It's about recognizing that every extension you install is running code on your machine with access to your files and credentials — and making deliberate decisions about which ones you trust.
Run the code --list-extensions audit today. Remove anything unused. Set a quarterly reminder. That's the whole job.