IDE Extension Supply Chain: How to Verify a VS Code Extension Before You Install It

Most of us install an IDE extension the way we used to install browser toolbar junk: one click, a glance at the star count, done. The difference is that an extension runs inside your editor, with your files, your terminal and very often your git and SSH setup within reach. The publisher badge tells you who published it once. It does not tell you what the update that landed on your machine this morning actually does. Here is how to check an extension before you trust it, what each check catches, and where each one stops working.

Before you read: The Chrome extension permissions guide covers the same trust question for browser add-ons, and the AI agent sandboxing guide explains what happens once an extension can reach the network. You do not need either one to follow this piece, but both sharpen the threat model.

Why now: Reports this week say a malicious build of Anthropic’s Claude Code extension was available through Cursor’s marketplace for hours before it was dealt with. I could not confirm those details against the original reports while writing this, so the incident serves here as an example, not as evidence.

Table of contents

• The Badge Is a Receipt, Not a Warranty
• Four Checks You Can Run Before the Update
• A Comparison of the Checks
• Where the Method Breaks
• Fun Facts
• Sources

The Badge Is a Receipt, Not a Warranty

A verified publisher badge tells you that someone checked an identity at some point. Think of it as a bouncer who checked your ID in March. It says nothing about who holds the keys today. If an attacker takes over a trusted publisher account, the next version they push carries the same name, the same icon and the same badge, and anyone with auto-update enabled gets it without a prompt.

Names are the other weak point. Every developer has searched a marketplace for a formatter and scrolled past three near-identical listings before finding the right one. Attackers are counting on that scroll.

Forks add a second question. Cursor and other VS Code forks do not always pull from the same store Microsoft operates. Before you trust a listing, find out which registry your editor is talking to, because the rules you are reading about belong to that registry and to no other.

Four Checks You Can Run Before the Update

1. Pull the package, not the listing. A .vsix file is a ZIP archive. Download the exact version you plan to install and list what is inside:

unzip -l example-publisher.example-tool-1.4.2.vsix

Everything the editor will execute lives under extension/. Start with extension/package.json and read four fields: publisher, repository, main and activationEvents. An activationEvents entry of * means the extension loads at startup, before you have opened a single file. A repository field that is missing or points to a project with no recent commits is worth a note, not a verdict.

2. Diff the version you have against the one you are about to get. Most suspicious updates are small: a new dependency, a new network host, one new call to child_process. Unpack both versions and compare them:

unzip -q old.vsix -d old && unzip -q new.vsix -d new
diff -rq old/extension new/extension

Then list every URL the new build mentions:

grep -rhoE 'https?://[A-Za-z0-9._/-]+' new/extension | sort -u

A host that appears only in the new version is the question to answer before you click update. Minified bundles make the diff noisy, so start with the dependency list in package.json and then look at the bundle itself.

3. Grep for behaviour an editor extension rarely needs. A formatter has no business writing to your home directory. This pattern catches most of the code paths that matter for a backdoor:

grep -rnE 'child_process|authorized_keys|[.]ssh|new Function|eval[(]' new/extension

Expect false positives. Plenty of legitimate tools call child_process to run git. A hit is a question for the code, not a verdict. A hit on authorized_keys, though, deserves a full stop.

4. Snapshot the disk around the install. Static review misses anything fetched at runtime, so check what the editor changed. On macOS and Linux:

ls -la ~/.ssh && cat ~/.ssh/authorized_keys

Run it before installing and again afterwards. On Windows, the same folder sits under your %USERPROFILE% directory, in its .ssh subfolder. A new key file or a changed authorized_keys is the cheapest signal in this whole method, and it takes seconds.

5. Pin what touches your credentials. Pinning stops the silent update that delivers a bad build, and it also stops the security fix that ships in the next one. The trade-off is real. My rule is to pin extensions that can read your files, your terminal or your tokens, and let themes and icon packs update on their own. To install a specific version, the CLI form is code --install-extension publisher.name@version. Run code --help on your build to confirm the flags, because I have not checked them against the current release.

A Comparison of the Checks

No single check is enough, and each one has a blind spot that another covers. The table is the version I would tape to the monitor.

Check	Catches	Misses
Publisher badge and listing age	Lookalike names from new publishers	A trusted account that has been taken over
Version diff	New hosts, dependencies and calls in an update	A malicious first release with no baseline to compare
Static grep	Shell, SSH and eval patterns in plain code	Obfuscated code and payloads fetched at runtime
Disk snapshot	Files and keys the extension wrote	Anything kept in memory or staged for later
Egress monitoring	Connections to hosts you never allowed	Dormant code that waits for a later date

The first two rows describe the path a compromised update takes into your editor. The last three describe what happens after it arrives. The sandboxing guide covers the egress row in depth, and it is the row most people skip.

Where the Method Breaks

Nobody reads the bundle of a formatter line by line on a Tuesday afternoon. Most developers will run steps one and three, skip two, and trust the rest. That is a reasonable amount of paranoia for a theme and nowhere near enough for an extension that can see your production keys. The honest version of this guide says: pick the extensions that touch credentials, put them under the full procedure, and accept the risk on the rest.

The deeper limit is that a package audit describes what the extension contains, not what a server sends it next week. Marketplace screening helps, but once a package is installed, the checking falls back on you.

Fun Facts

• The archive hiding in plain sight: A .vsix file is a ZIP. If you can run unzip, you can read an extension’s source before your editor does.
• Five seconds of evidence: An extension that writes an SSH key leaves a file in your .ssh folder. A plain ls will show it, with no security tooling required.
• Your editor is a user-level program: Extensions generally run with your account’s permissions, which is why your SSH keys and git tokens sit within reach of code you installed to get a linter.

Sources

• BleepingComputer, report on a malicious Claude Code extension distributed through Cursor (cited via the wire brief, not independently fetched): https://www.bleepingcomputer.com/news/security/malicious-claude-code-extension-on-cursor-planted-ssh-backdoors/
• Ars Technica, report on the same incident (cited via the wire brief, not independently fetched): https://arstechnica.com/security/2026/10/anthropic-vs-code-extension-on-cursor-backdoored-for-nearly-12-hours/
• VS Code and Visual Studio Marketplace documentation, for CLI flags and publisher verification details: not fetched for this article; confirm before relying on the install syntax above.