What is VS Code extension security?
VS Code extension security is the practice of assessing, controlling, and monitoring extensions installed in Visual Studio Code and compatible editors to reduce risks such as malicious code execution, credential theft, persistence, unsafe updates, impersonation, and supply chain compromise.
It includes both prevention before installation and monitoring after an extension is trusted.
This differs from browser extension security because IDE extensions operate inside a developer workflow with access to code, local files, terminals, project configuration, and other high-value context.
Why VS Code extensions are high-value targets
A developer workstation contains more privileges than an ordinary endpoint. It can have source code for internal products, GitHub or GitLab credentials, cloud CLI sessions, package registry tokens, SSH keys, Kubernetes configuration, local environment files with API keys, and access to AI coding agents and MCP servers.
A malicious extension does not need to exploit the editor if the platform already grants enough capability to accomplish the attack.
Common VS Code extension attack patterns
- Impersonation and typosquatting: An attacker publishes an extension that resembles a legitimate product or trusted publisher.
- Malicious startup behavior: An extension activates automatically when the editor opens and downloads or runs additional code.
- Remote payload delivery: An extension looks clean during static review because the malicious command or payload is fetched from an external server later.
- Compromised updates: A trusted extension or publisher account changes hands or is compromised after accumulating installs.
- Credential theft: An extension reads local secrets, tokens, environment variables, or repository credentials.
- Persistence and defense evasion: More sophisticated campaigns use the extension as the first stage for continued access to the developer environment.
What Pluto’s research has found
Pluto Security Research has documented multiple active campaigns involving malicious VS Code and Open VSX extensions.
Nebula Deck, Pluto’s flagship investigation into this threat, analyzed impersonation-style extensions and the specific techniques attackers use to make a malicious listing look legitimate enough to install, including patterns that triggered multi-stage compromise once the editor loaded. PhantomBoard, a related Pluto campaign in the same research line, documented a further set of malicious extension techniques that add to those findings.
The recurring lesson across both: marketplace presence and a plausible user interface are not sufficient evidence that an extension is safe.
How to secure VS Code extensions
- Inventory installed extensions, since security teams need visibility across the fleet rather than relying on individual developers to remember what they installed.
- Control publishers and sources, using allowlists or policy for high-risk environments, especially where multiple marketplaces or VS Code forks are in use.
- Review activation behavior, since extensions that execute automatically at editor startup deserve more scrutiny than passive syntax or theme packages.
- Monitor network behavior, since unexpected outbound connections can reveal payload retrieval or data exfiltration that static marketplace review missed.
- Treat updates as new code, since a trusted extension can become malicious later; monitor version changes, publisher changes, and new permissions.
- Connect extension risk to AI tooling, since AI-enhanced editors and coding agents can make extensions part of a larger agentic workflow, increasing the amount of sensitive context available to a compromised extension.
VS Code extension security vs. Open VSX marketplace security
Both matter, and they answer different questions, and neither replaces the other.
- VS Code Extension Security: This focuses on the extension itself: what it does once installed, and how to detect and control that behavior regardless of where it came from.
- Open VSX marketplace security: This focuses on the trust model of one specific open-source registry that many VS Code forks depend on, and why that registry’s more open publishing model changes the calculation.
Final thoughts
VS Code extensions are part of the software supply chain even when they are not part of the application being built. They execute in the environment where software and credentials live, which makes them attractive targets for attackers.
A secure program combines marketplace awareness, extension inventory, publisher and update controls, and runtime monitoring rather than assuming a one-time extension review is permanent trust.
FAQs
1. Are extensions from the official VS Code Marketplace automatically safe?
No. Marketplace review reduces risk but does not guarantee that an extension is safe, as malicious or compromised extensions can still appear. Pluto’s own research has documented live malicious campaigns involving trusted-looking marketplace listings.
2. Can a VS Code extension steal credentials?
Potentially, yes. Extensions can run with access to local developer context, and a malicious one may attempt to read tokens, configuration files, or other secrets available to the user.
3. Should enterprises block all third-party extensions?
Not necessarily. Use inventory, trusted publishers, allowlists where appropriate, update monitoring, and behavioral detection rather than treating every extension as equally risky.
4. How do AI coding tools change extension risk?
AI coding agents can expand the workflow around the editor, including adding tool calls, MCP connections, and richer access to code and local context. A compromised extension can therefore become part of a larger AI-enabled attack path.
5. How does this relate to Nebula Deck and PhantomBoard?
Both are Pluto Security Research campaigns in the same research line, each documenting different specific malicious-extension techniques within the broader VS Code and Open VSX threat. See the Nebula Deck entry for the flagship investigation.