Software Supply Chain

What is IDE extension security?

IDE extension security addresses the risks posed by extensions and plugins installed in development environments like VS Code, Cursor, and JetBrains IDEs. With over 60,000 extensions in the VS Code Marketplace alone (3.3 billion total installs) and 1,283 found to have malicious dependencies accounting for 229 million installs, extensions are a significant and largely unmonitored attack surface. Extensions run with full trust inside the IDE process, with no sandboxing or runtime permission model.

What Is / Definition

IDE extension security is the practice of identifying, monitoring, and governing the extensions and plugins installed in developers' integrated development environments. It has become a critical concern because of the scale, trust model, and lack of oversight in modern extension marketplaces. The VS Code Marketplace — the largest IDE extension ecosystem — hosts over 60,000 extensions with more than 3.3 billion cumulative installs. The average developer has 40+ extensions installed. These extensions handle everything from syntax highlighting and code formatting to AI code generation, database access, and deployment automation. The security problem is rooted in how extensions operate. Unlike mobile apps, which run in sandboxed environments with explicit permission models, IDE extensions run with full trust inside the IDE process. A VS Code extension has access to the filesystem, the network, the terminal, and every file open in the editor. There is no permission dialog. There is no runtime isolation. A malicious extension has exactly the same access as a legitimate one. Research has confirmed the risk at scale. Security researchers identified 1,283 VS Code extensions with known malicious dependencies, collectively installed 229 million times. These extensions either directly contained malicious code or depended on npm packages with documented vulnerabilities or malicious payloads. The problem extends beyond VS Code. Cursor, which has rapidly gained developer adoption for its AI capabilities, uses the same extension architecture. JetBrains IDEs have their own marketplace with similar trust assumptions. As developers move between IDEs — increasingly common in the vibe coding era — they carry their extension habits with them, installing similar functionality across multiple environments. For security teams, IDE extensions represent a category of software that is installed freely by developers, runs with elevated privileges, and is invisible to most endpoint security tools. EDR solutions see the IDE as a single trusted process and do not inspect extension behavior within it.

Why It Matters

IDE extension security matters because extensions are one of the highest-privilege, lowest-visibility software categories on a developer's machine. Consider what a malicious extension can do. It runs inside VS Code with the developer's full permissions. It can read every file in the workspace — including source code, environment files containing API keys, and configuration files with database credentials. It can make network requests to exfiltrate data. It can modify files silently. It can access the terminal and execute commands. And it does all of this while appearing as a legitimate, installed extension that the developer chose. The marketplace model amplifies the risk. The VS Code Marketplace has minimal vetting. Extensions are published by anyone with a Microsoft account. While Microsoft performs some automated scanning, the volume — 60,000+ extensions — makes comprehensive review impossible. Typosquatting is common: attackers publish extensions with names similar to popular ones, counting on developers to install the wrong one. The organizational scale makes manual governance impractical. Across a fleet of 300 developer machines with an average of 40+ extensions each, that is 12,000+ extension installations to track. Extensions update automatically. New extensions are installed daily. Without automated inventory and monitoring, security teams have no way to know what is running, let alone whether it is safe. Real-world consequences are documented. The 229 million installs on extensions with malicious dependencies represent real developer machines that were exposed. In many cases, the malicious behavior was in a transitive dependency — a package the extension depended on, not the extension itself — making it invisible even to developers who reviewed the extension's source code.

How It Works

IDE extension security risks operate through several specific mechanisms that security teams should understand. The trust model. When a developer installs a VS Code extension, it runs inside the VS Code process with no sandboxing. The extension's code executes in the same Node.js runtime as VS Code itself. It can use VS Code's APIs to access the workspace, read and write files, interact with the terminal, and make HTTP requests. There is no user-facing permission prompt. The extension is fully trusted from the moment it is activated. Malicious dependency chains. An extension might be benign in its own code but depend on npm packages that are compromised. When the extension is installed or updated, its dependencies are pulled and executed. The 1,283 extensions with malicious dependencies were largely compromised through this vector — the extension authors may not have intended harm, but their dependency tree included packages with malicious payloads. Data access and exfiltration. Extensions can read workspace files (source code, .env files, configuration), access VS Code's settings and secrets store, monitor keystrokes through editor event listeners, and make outbound network requests. A malicious extension can harvest credentials, source code, or proprietary data and transmit it externally without triggering EDR alerts because the traffic originates from a trusted process. Update as attack vector. Extensions update automatically by default. An extension that was safe when installed can become compromised through an update — either because the extension author's account was hijacked, or because a dependency in the extension's chain was compromised upstream. The September 2025 incident where 20 npm packages with 2 billion weekly downloads were compromised illustrates how upstream changes cascade to downstream consumers, including IDE extensions. Invisible to EDR. Endpoint detection tools monitor at the process level. VS Code is a single trusted process. Everything that happens inside it — including malicious extension behavior — is attributed to the VS Code process, not to the individual extension responsible.

Key Takeaways

  • IDE extensions run with full trust inside the IDE process — no sandboxing, no permission model, no runtime isolation — making them a high-privilege attack vector.
  • The VS Code Marketplace hosts 60,000+ extensions with 3.3 billion installs; 1,283 were found with malicious dependencies totaling 229 million installs.
  • Extensions can access the filesystem, network, terminal, and every open file, enabling data exfiltration, credential theft, and code manipulation.
  • Automatic updates mean a safe extension can become compromised at any time through upstream dependency changes or account hijacking.
  • EDR cannot distinguish malicious extension behavior from legitimate IDE activity because extensions run inside the trusted IDE process.
  • View in the Safety glossary