Several popular AI-powered integrated development environments built on forks of Microsoft Visual Studio Code were found to expose developers to a significant software supply chain risk through their built-in extension recommendation systems. The issue stems from these IDEs recommending extensions that did not exist in the OpenVSX registry, leaving unclaimed publisher namespaces open for registration by anyone and potentially usable for malicious extension distribution.
The affected tools include Cursor, Windsurf, Google Antigravity, and Trae. All are based on VSCode but cannot use Microsoft’s official Visual Studio Marketplace due to licensing restrictions. Instead, they rely on OpenVSX, an open-source extension registry maintained by the Eclipse Foundation.
While these IDEs transitioned to a different extension marketplace, they inherited VSCode’s hardcoded extension recommendation logic. That logic continued to reference extension identifiers originally intended for Microsoft’s marketplace, creating a mismatch between trusted IDE recommendations and actual extension availability in OpenVSX.
The Risk Created by Extension Recommendations
Extension recommendations in VSCode-based editors operate as privileged trust signals rather than passive suggestions. These prompts are generated automatically by the IDE based on detected file types, installed software, or project configuration, and are presented as official guidance. Because the recommendation originates from the development environment itself, users are conditioned to assume the extension is safe, vetted, and appropriate to install.
There are two primary types of extension recommendations. File-based recommendations are triggered when a developer opens specific files such as azure-pipelines.yaml or build.cake, prompting the IDE to suggest an extension associated with that file type. Software-based recommendations occur when the IDE detects installed components like PostgreSQL or the Heroku CLI and automatically suggests a related extension.
In the affected VSCode forks, these recommendation rules referenced extension identifiers that did not exist in the OpenVSX registry. Since OpenVSX allows open registration of unused publisher namespaces, these missing identifiers created an opportunity for anyone to claim the namespace and upload an extension. This transformed a trusted IDE recommendation mechanism into a potential malware delivery channel without requiring phishing, impersonation, or overt user deception beyond the initial trust placed in the IDE.
How a Supply Chain Attack Could Occur
If a threat actor claimed one of the unregistered namespaces and uploaded a malicious extension, the IDE would present it to users as a recommended extension. No phishing emails, fake websites, or social engineering steps would be required beyond the implicit trust of the IDE itself.
A developer following normal workflow would see the recommendation, install the extension, and grant it the same level of access as any legitimate plugin. That access can include reading source code, accessing environment variables, interacting with the file system, and in some cases accessing sensitive credentials such as SSH keys, cloud tokens, or API secrets.
Because the extension is installed through an official recommendation channel, its activity would appear normal to most users and difficult to distinguish from legitimate development behavior.
What Was Discovered by Researchers
Researchers from supply chain security firm Koi identified that several highly trusted extension identifiers were unclaimed in the OpenVSX registry. These identifiers were associated with commonly used development tools, including Azure DevOps, PostgreSQL, Heroku, and related ecosystems.
To prevent malicious exploitation, the researchers proactively registered the vulnerable namespaces themselves and uploaded non-functional placeholder extensions. These extensions provided no functionality and explicitly stated they were placeholders.
Despite this, hundreds of developers installed the placeholder extensions solely because their IDE recommended them. This demonstrated how strongly users trust IDE-driven recommendations and how severe the risk could have been if a malicious actor had claimed the namespaces first.
Affected IDEs and Vendor Responses
The researchers disclosed the issue to multiple vendors in late November 2025. Cursor acknowledged the problem and implemented a fix on December 1, 2025. Google Antigravity initially marked the report as infeasible before later removing a subset of extension recommendations and marking the issue as fixed on January 1, 2026.
At the time of reporting, Windsurf had not issued a public response to the disclosure.
In parallel, the researchers coordinated with the Eclipse Foundation to review remaining referenced namespaces, remove non-official contributors where necessary, and apply additional safeguards at the registry level.
Why This Issue Matters Beyond These IDEs
This incident highlights a broader structural weakness in extension ecosystems. Recommendation systems function as high-trust channels. When these systems are inherited through forks without re-evaluating underlying assumptions, they can silently introduce new attack surfaces.
The issue was not a flaw in OpenVSX itself, nor was it a traditional vulnerability in VSCode. It was a trust boundary mismatch. The IDEs assumed recommended extensions were inherently safe, while the registry model allowed unrestricted namespace registration.
As AI-assisted development tools accelerate adoption and reduce friction around installing extensions, these trust failures become increasingly dangerous. The faster developers move, the less likely they are to manually vet recommended components.
What Developers and Organizations Should Do
Developers using VSCode forks should treat extension recommendations as part of their software supply chain rather than as trusted defaults. Even when an extension is suggested directly by the IDE, it should be manually reviewed by verifying the publisher identity, confirming it is officially maintained, and checking that it exists in the expected registry with a clear project history.
Organizations should apply governance controls to IDE extensions in the same way they manage third-party libraries and dependencies. This can include restricting installations to approved publishers, enforcing extension allowlists, and auditing which plugins are installed across development environments. Extensions that request access to source code, credentials, or network resources should be subject to heightened scrutiny.
Security teams should explicitly include IDE extensions in their threat models and monitoring strategies. A malicious extension installed through a trusted recommendation channel can have the same impact as a compromised dependency, including credential theft, source code exfiltration, and persistent access to development systems.
To further reduce exposure, teams should monitor for unusual IDE behavior such as unexpected network connections, background script execution, or abnormal file system access originating from extension processes. Awareness and visibility, rather than blind trust in recommendations, remain the most effective defenses against this class of supply chain attack.
The Larger Supply Chain Lesson
This case demonstrates how trust, rather than software vulnerabilities, is increasingly the weakest link in modern development ecosystems. No exploit was required and no code flaw was abused. The risk emerged entirely from implicit trust in inherited systems.
As development environments continue to evolve and fork from established platforms, recommendation logic, namespace ownership, and trust boundaries must be treated as core security considerations. Failing to address these issues leaves even experienced developers exposed to attacks that are indistinguishable from normal workflow.
