The VS Code extension marketplace is the single largest unvetted code-execution surface on most developer workstations, and the industry has been remarkably comfortable ignoring this fact. An extension runs in the same process as the editor, has the editor's full filesystem access, can read every file you open, and can make arbitrary network requests. It is, functionally, a backdoor that you opted into by clicking install.
This post is about how bad the problem actually is in 2026, what the real attacks have looked like, and what the realistic mitigations are for an organization that cannot just ban extensions outright.
What does the threat model actually look like?
A VS Code extension runs as a Node.js process spawned by the editor. It has access to the editor's API, which includes reading and writing files in any open workspace, executing terminal commands, and exfiltrating data over arbitrary network connections. The extension does not run in a sandbox in any meaningful sense. The marketplace performs some automated scanning, but it is shallow, and there is no human review for the vast majority of extensions.
The implications are straightforward. An extension installed by a developer working on a codebase containing customer data has access to that customer data. An extension installed by a developer who runs git commit from the integrated terminal has access to the developer's git credentials. An extension that an attacker has compromised, through a maintainer account takeover or by purchasing the extension from its original author, can pull all of this immediately on next launch. The 2023 incidents where multiple VS Code extensions were found to contain malicious code, including the takeovers of legitimate extensions, demonstrated that this is not a theoretical concern.
What have the real takeovers looked like?
The 2023 wave of malicious VS Code extensions established the template. In several documented cases, attackers either published typosquats of popular extensions or, more interestingly, took over abandoned-but-still-installed extensions through credential reuse or social engineering of the original maintainer. The compromised extensions exfiltrated environment variables, SSH keys, and the contents of recently opened files. Several remained on the marketplace for weeks before removal.
A separate category of incident has involved legitimate extensions adding aggressive telemetry or third-party SDKs that, while not strictly malicious, exfiltrate enough metadata to compromise privacy and in some cases security. The pattern is familiar from the browser extension ecosystem, where a respected extension is sold to a company that adds analytics, and the user community discovers the change only after the new build has been pushed to millions of installs. VS Code's marketplace has no equivalent of the Chrome Web Store's mandatory disclosure for ownership transfers, which is a meaningful gap.
How can you actually restrict what extensions get installed?
The native control is the extensions.allowed setting introduced in 2024, which lets an organization specify an allowlist of extensions and block all others through a managed settings file. This is the right control for any environment with a reasonable workstation management story. Deploy the managed settings through your MDM, point it at a curated allowlist, and audit the list quarterly.
The allowlist itself is the hard part. A list of fifty common extensions is easy; a list that satisfies every team's actual needs is much larger and changes constantly. The pragmatic approach is to start with a permissive allowlist that covers the top hundred or so extensions and a fast-track process for requesting additions, then tighten it as you collect data on actual usage. The mistake is to start strict and then deal with a constant stream of escalations; you will burn organizational goodwill on a control that ends up watered down anyway.
What about workspace trust and the integrated terminal?
VS Code's workspace trust feature, which prompts before running tasks or debuggers from a newly opened folder, is a useful but imperfect control. It defends against the specific case where a developer opens a repository containing a malicious tasks.json or .vscode/settings.json that would otherwise auto-execute. It does not defend against an installed extension that fires on workspace load, because installed extensions are trusted by default.
The integrated terminal is a bigger concern in 2026 than it was a few years ago, because the rise of AI coding assistants has normalized extensions that execute shell commands as part of their normal flow. Any extension with terminal access has, effectively, root on the workstation from the perspective of any process the developer could run from a terminal. Hardening here means restricting the set of extensions that have terminal access through the manifest review, and disabling the terminal API for extensions that do not need it via the terminal.integrated.allowChords and related settings, though the controls here are still weaker than they should be.
What workstation-level controls actually help?
Endpoint detection and response on developer workstations, configured to flag the patterns that malicious extensions use, is the most effective compensating control. The patterns are not subtle: a Node.js process spawned by VS Code making outbound connections to unfamiliar hosts, reading SSH key files, or shelling out to git for credential commands. A correctly tuned EDR catches these reliably; the challenge is the false-positive rate, because legitimate extensions do many of the same things.
Network egress controls are also genuinely useful. A workstation that can only reach a managed proxy, which logs and filters outbound connections, makes exfiltration much harder. The 2023 extension incidents were noisy on the network; they would have been caught immediately by a proxy that flagged unusual destinations. The trade-off is developer experience, because legitimate extensions also make network requests, and a proxy that breaks them produces support tickets. The right calibration depends on your environment's security posture.
How Safeguard Helps
Safeguard treats developer workstations as part of the supply chain, because they are. Our endpoint integration ingests the extension inventory from VS Code, JetBrains IDEs, and similar tools, then evaluates each extension against our TPRM scoring and the zero-day feed. Griffin AI surfaces extensions with anomalous behavior, recent maintainer changes, or active threat intelligence indicators. Reachability analysis tells you which extensions actually touch sensitive repositories, so the prioritization is grounded in real exposure. Policy gates can block CI runs that originate from a developer whose workstation has an extension on the deny list, closing the loop from endpoint posture to deployment control. The marketplace is not going to fix itself; the platform is where you compensate.