Every developer who installs a VS Code extension is granting it the same filesystem, network, and process access as the editor itself — and Wiz Research's 2025 marketplace audit found that trust is routinely misplaced. Scanning public extensions on the VS Code Marketplace and the Open VSX registry, Wiz validated more than 550 leaked secrets spread across 500-plus extensions from hundreds of publishers. In over 100 of those cases, the leaked credential was a publisher access token — not a customer's API key, but the token an attacker could use to push a malicious update directly to that extension's entire existing install base, silently, without the developer ever re-approving anything. Layer that onto a separate 2025 trend: security researchers tracked what reporting describes as a roughly fourfold year-over-year jump in malicious-extension detections, with named campaigns like "TigerJack" (11-plus malicious extensions across multiple publisher accounts since early 2025) and "prettier-vscode-plus," a Prettier impersonator published November 21, 2025. IDE extensions have quietly become as significant a supply-chain surface as npm or PyPI packages — this post covers how to evaluate, restrict, and monitor them.
Why does a compromised extension matter more than a compromised package?
A compromised extension matters more because it runs with the IDE's own privileges, continuously, on every project you open — not once, at install or build time, like most package-level malware. A malicious npm package typically executes during npm install or when explicitly imported; a malicious extension runs every time you launch your editor, with access to your open files, terminal, clipboard, and any credentials your IDE can reach (SSH keys, cloud CLI tokens, .env files in your workspace). Extensions also auto-update by default in most editors, meaning a publisher-token compromise — the exact vector Wiz documented — can flip a trusted, years-old extension into malware for its entire installed base overnight, with no new user action required. That combination — high privilege, continuous execution, and silent auto-update — is why extension compromise is a more severe supply-chain event than a single bad package version, even though both start the same way: a developer clicking install on something that looked legitimate.
Does a "Verified Publisher" badge mean the code is safe?
No — a Verified Publisher badge confirms the publisher controls a claimed domain, not that the extension's code is safe or behaves as described. Both Checkmarx and Wiz have documented this as an exploitable trust gap: developers routinely treat the blue checkmark as a safety signal, but Microsoft's verification process attaches the badge based on domain ownership, and domain ownership is comparatively cheap for an attacker to establish or spoof through a lookalike organization. The badge says nothing about whether the extension's manifest requests excessive permissions, whether its bundled code has been reviewed for behavior, or whether the publisher's own account credentials are properly secured — the exact gap the leaked publisher-token cases exploited. Treat the badge as one weak signal among several, not a substitute for reviewing what an extension actually does, who publishes it, and how long it's had a stable, reviewable history.
What is Microsoft doing about it, and what does that leave uncovered?
Microsoft's Marketplace now scans newly published extensions for embedded secrets and credentials and blocks publishing when it finds them — a real control, but a narrow one. It catches an extension shipping a hardcoded key in its own source; it does not perform behavioral review of what the extension does at runtime, does not vet permission scope against stated purpose, and does not stop a previously-clean extension from turning malicious after a publisher-token takeover, since the update itself may contain no embedded secret at all. VS Code separately ships Workspace Trust and Restricted Mode, which limit what code can execute automatically when you open an unfamiliar folder, and a documented Extension Runtime Security posture in its official docs — both genuine defense-in-depth, but both opt-in behaviors a team has to actively configure rather than defaults that quietly protect everyone.
What should a team actually do to restrict extension risk?
Treat IDE extensions as first-class dependencies subject to the same review discipline as a package.json entry, not a personal preference left to individual developers. Concretely: maintain an org-managed extension allowlist (VS Code and JetBrains both support enterprise policies that restrict installs to an approved list or a private, internally-curated marketplace); pin extension versions instead of leaving auto-update on for anything with filesystem or network access beyond syntax highlighting; require a documented reason and reviewer sign-off before a new extension joins the allowlist, checking publisher history, install count trajectory, and recent permission changes; and if your organization also publishes extensions, rotate and scope publisher API tokens the same way you would a CI/CD deployment key, since that token is the exact artifact Wiz found leaked in over 100 cases. None of this requires exotic tooling — it requires applying dependency-management hygiene to a category of software most teams have never formally reviewed.
How does this connect to package-level supply-chain defenses teams already run?
Extension vetting and package vetting are related but distinct problems, and it's worth being precise about where each control actually applies. Safeguard's own IDE extension is itself distributed through the VS Code Marketplace and Open VSX — the same channels this post is describing risk in — so this is a category Safeguard ships into, not just writes about. Inside that extension, the Package Firewall's inline checks (typosquat detection, dependency/namespace-confusion flags, a known-malicious blocklist, and static behavioral analysis) scope specifically to the npm and pip dependencies a developer is adding to a manifest as they type — they evaluate what's going into your project's dependency tree, not the extension ecosystem itself. That's a meaningfully different attack surface: a clean Package Firewall verdict on your package.json says nothing about whether an unrelated, unreviewed extension sitting in the same editor has a stale publisher token. Both need review; neither substitutes for the other, and treating extension marketplaces with the same scrutiny you already apply to package registries closes a gap most security programs haven't formally acknowledged yet.