VS Code Forks Recommend Missing Extensions, Exposing Developers to Serious Supply-Chain Risk

Developers relying on AI-powered forks of Microsoft Visual Studio Code (VS Code) have been warned of a subtle but potentially serious security gap that can be exploited for supply-chain attacks. Tools such as Cursor, Windsurf, Google Antigravity, and Trae — popular alternatives built from the VS Code codebase — are inadvertently recommending extensions that do not actually exist in the open-source Open VSX extension registry. This mismatch opens the door for malicious actors to upload rogue packages under those names and trick developers into installing malware.

The implications of this discovery go far beyond mere inconvenience — they highlight an evolving threat space where trusted developer tools can be weaponized to compromise entire development environments, steal sensitive data, or inject malicious code into software supply chains.

Understanding the Issue: How Recommendations Turn Into Risk

At the heart of the problem is a structural mismatch between where extensions are recommended and where they are actually published.

Microsoft’s official Visual Studio Code marketplace includes thousands of extensions with curated metadata and publisher identities. When you open certain file types or detect installed software, VS Code may suggest relevant extensions — for example, recommending PostgreSQL-related tools when you edit SQL files.

AI-powered forks of VS Code such as Cursor, Windsurf, Google Antigravity, and Trae inherit these hardcoded extension recommendations from the original VS Code configuration. However, due to licensing restrictions, these forks can’t use the Microsoft marketplace directly. Instead, they rely on Open VSX, an open-source extension registry overseen by the Eclipse Foundation.

The critical flaw is this: many of the recommended extensions simply don’t exist in Open VSX, meaning their namespaces in that registry are unclaimed. Since Open VSX allows anyone to register a previously unused package name, this creates a supply-chain vulnerability: bad actors could register those extension names themselves and upload malicious code in their place.

Two Recommendation Pathways Increase the Risk

The VS Code forks issue arises through two common extension recommendation mechanisms:

1. File-based recommendations – These are triggered when a developer opens a specific file type associated with a particular extension, like .sql files prompting a PostgreSQL extension suggestion.
2. Software-based suggestions – If the IDE detects certain software installed on a developer’s system (e.g., a particular CLI tool or database engine), it may recommend related extensions to enhance the development experience.

Both mechanisms issue suggestions directly through the IDE interface — complete with clickable prompts to install the recommended extension — encouraging developers to simply click and install.

Unfortunately, because the recommended extension identifiers were inherited from the VS Code marketplace but never validated against the Open VSX registry, some recommendations point to non-existent packages. These unclaimed namespaces are exactly where an attacker could step in.

How an Attack Could Play Out

In a realistic supply-chain attack scenario:

1. A threat actor monitors the list of extension names recommended by the VS Code fork IDE — focusing on ones that don’t exist in Open VSX.
2. They register one or more of these unclaimed extension names in the Open VSX registry.
3. A developer using an affected IDE opens a relevant file type or has supporting software installed. The IDE recommends a “missing” extension, now registered by the attacker.
4. Trusting the suggestion, the developer installs the extension. Because it’s installed through the IDE’s trusted recommendation UI, that extension is likely granted permissions just like any legitimate extension.
5. The malicious extension can then run arbitrary code, exfiltrate credentials, access local or remote source code, read environment variables, or move laterally within a development or production network.

This kind of attack doesn’t require phishing, social engineering outside the IDE, or visible deception — the trust implicit in the recommendation UI can be enough to lure developers into installing damaging software.

Proof of Concept: Placeholder Extensions & Early Adoption

Security researchers at Koi Security demonstrated just how quickly this risk could translate into real action. They created placeholder versions of several widely-recommended extension names that were absent from Open VSX and published them in those namespaces. Despite these placeholder packages offering no functionality, hundreds of developers installed them just because they appeared in the IDE recommendation list.

Some of the extension names captured by Koi Security — now blocked by placeholder packages — include:

• ms-ossdata.vscode-postgresql
• ms-azure-devops.azure-pipelines
• msazurermtools.azurerm-vscode-tools
• usqlextpublisher.usql-vscode-ext
• cake-build.cake-vscode
• pkosta2005.heroku-command

The rapid uptake of these placeholders underscores how much developers rely on IDE recommendations and how easily an attacker could insert malicious replacements.

Vendor and Community Responses

After responsible disclosure, some affected IDE vendors took action to mitigate risk:

• Cursor rolled out a fix as early as December 1, 2025 to prevent recommending missing extensions within its UI.
• Google Antigravity removed a set of extension recommendations later in December and confirmed the issue was addressed by January 1, 2026.
• Windsurf had not publicly responded to the researchers at the time of reporting, leaving some users potentially exposed.
• The Eclipse Foundation, which maintains the Open VSX registry, has also implemented updated safeguards and removed potentially unsafe contributors to harden the registry itself.

Despite these efforts, the broader lesson — that trusted recommendation systems can create trust failures — remains relevant for organizations and individual developers alike.

Why This Matters: Beyond a Simple Bug

This issue isn’t a typical code vulnerability such as SQL injection or remote code execution. Instead, it’s a supply-chain weakness rooted in trust and ecosystem design.

The breach model here is not about exploiting a flaw in the IDE’s codebase per se, but about abusing recommendation logic combined with extension registry governance. The mismatched trust boundaries — where an IDE assumes recommendations point to legitimate, vetted extensions but in fact they might not exist in the target registry — create an implicit vector for attacks.

The risk is similar to other supply-chain attacks seen in package registries, container ecosystems, and library repositories, where typosquatting or malicious naming is used to push malicious code under plausible-looking names. What makes this case unique is that it targets development tools themselves — the very environment where code, intellectual property, deployment scripts, and infrastructure secrets often reside.

Real-World Impact: Developers Are Targets Too

Developers and development machines are not isolated from the rest of an organization’s security perimeter. Many IDE extensions request broad permissions, including:

• Access to source code folders
• Reading environment variables
• Interacting with network APIs
• Launching background processes
• Storing or accessing credentials and secrets

A malicious extension installed through trusted IDE recommendations could silently run code that steals SSH keys, API tokens, database connection strings, or cloud access keys. In worst-case scenarios, this can allow attackers to breach corporate networks, exfiltrate proprietary source code, or compromise production environments without ever needing to breach external perimeter defenses.

Best Practices for Developers and Organizations

Given this emerging class of supply-chain risk, developers and security teams should adopt stronger controls around extension installation and extension trust. Key recommendations include:

1. Verify Extension Existence Before Installation

Never install an extension simply because the IDE recommends it. Always search for the extension directly in the Open VSX registry (or official marketplace) and check that it is maintained by a reputable publisher.

2. Validate Publisher Identity and History

Review publisher profiles, download counts, source repositories, and update history before installing extensions. Extensions with no history, unknown publishers, or sparse documentation should be treated with caution.

3. Restrict Extension Installation in Enterprise Environments

Organizations can enforce allowlists to restrict which extensions developers can install on managed workstations. This helps prevent rogue or unvetted extensions from entering critical workflows.

4. Educate Developers on Supply-Chain Risks

Security awareness training should include examples of how trusted UI recommendations can be exploited — and teach developers to treat extension ecosystems as part of the software supply chain.

5. Audit Development Environments Regularly

Use software composition analysis (SCA) and endpoint monitoring to detect unusual extension installations or suspicious behavior originating from developer machines.

The Larger Lesson: Trust Boundaries Matter

This case highlights a systemic truth about modern software development: trust boundaries are often the weakest link in a tech stack. Whether it’s package managers, dependency repositories, container registries, or IDE extension ecosystems, attackers are increasingly focusing on trusted channels rather than direct exploits.

AI-powered tools, with their convenience and automated recommendations, can accelerate development and productivity — but they also amplify trust. When tools suggest “use this extension,” many developers assume that suggestion is safe by default. As this incident demonstrates, that assumption is not always warranted.

Increasingly, security teams must treat these environments as part of the enterprise attack surface and apply governance, verification, and monitoring just as they do for code dependencies, libraries, and production software.

Conclusion: Caution Ahead for Developers Using VS Code Forks

VS Code forks like Cursor, Windsurf, Google Antigravity, and Trae have added powerful AI capabilities to the development experience. But the recent discovery that they recommend nonexistent extensions in the Open VSX registry has revealed a hidden attack vector that can undermine trust and expose developers to supply-chain attacks.

While fixes are rolling out and registry safeguards are being applied, the episode serves as a wake-up call for developers, security teams, and tool vendors alike: developer tools should never assume trust implicitly, especially when chaining recommendations across ecosystems with differing governance and validation models.

By adopting best practices around extension verification, publisher vetting, organizational controls, and developer education, teams can reduce risk and protect the integrity of their development environments against this and future supply-chain threats.