VSCode Forks Poisoned Fake Extensions in Trusted Tools

In the race to build the next generation of AI-powered development tools, a critical security oversight has emerged from an unexpected source: the very architecture that enables rapid innovation. Popular Integrated Development Environments (IDEs) like Cursor, Windsurf, Google Antigravity, and Trae—all forked from Microsoft's open-source Visual Studio Code—are inadvertently exposing users to sophisticated supply chain attacks through a seemingly benign feature: extension recommendations.

These AI-assisted platforms, while pushing the boundaries of developer productivity, have inherited a hidden vulnerability from their parent codebase. Due to licensing restrictions, these forks cannot connect to Microsoft's official Visual Studio Marketplace. Instead, they rely on OpenVSX, an open-source alternative registry for VSCode-compatible extensions. This architectural divergence has created a dangerous gap between intention and execution when it comes to extension recommendations—a gap threat actors are poised to exploit.

Mechanics of a Silent Threat

The vulnerability operates through two distinct recommendation pathways, both hardcoded into the forked IDEs:

File-based triggers: When a developer opens a specific file type (like `azure-pipelines.yaml`), the IDE automatically recommends a relevant extension (in this case, the Azure Pipelines extension).

Software-based detection: When the IDE detects specific software installed on a developer's system (such as PostgreSQL), it suggests corresponding extensions to enhance functionality.

The critical failure occurs because these recommendations—copied directly from VSCode's configuration—point to extensions in Microsoft's marketplace that do not exist in the OpenVSX registry. This leaves their corresponding publisher namespaces unclaimed and available for registration by anyone, including malicious actors.

Researchers from supply-chain security firm Koi identified this security gap and demonstrated how threat actors could:

Claim unclaimed namespaces for extensions that these IDEs automatically recommend
Upload malicious packages that appear as trusted recommendations to developers
Exploit developer trust in the IDE's built-in suggestion system

The table below outlines some of the critical namespaces that were vulnerable:

Extension Namespace	Associated Technology	Risk Level
`ms-ossdata.vscode-postgresql`	PostgreSQL	High
`ms-azure-devops.azure-pipelines`	Azure DevOps	High
`msazurermtools.azurerm-vscode-tools`	Azure Resource Manager	Medium
`usqlextpublisher.usql-vscode-ext`	Azure Data Lake	Medium

A Race Against Time

In late November 2025, Koi researchers responsibly disclosed their findings to the affected companies. The response timeline reveals concerning disparities in security prioritization:

Google acted swiftly, removing 13 vulnerable extension recommendations from its Antigravity IDE by December 26, 2025
Cursor and Windsurf had not responded or taken action at the time of reporting, leaving their users potentially exposed
Koi researchers proactively claimed six critical namespaces and uploaded non-functional placeholder extensions to prevent malicious exploitation
Eclipse Foundation (OpenVSX operators) collaborated to verify remaining namespaces and implement broader registry safeguards

This incident highlights a growing tension in the developer tools ecosystem: the push for AI-enhanced productivity versus foundational security hygiene. Forking established platforms like VSCode enables rapid feature development but also blindly inherits security assumptions that may not hold in new contexts.

Implications for Software Supply Chains

This vulnerability represents more than just another extension security issue—it exposes systemic weaknesses in how we manage forked software ecosystems:

Trust Transference Issues: Developers naturally extend trust from established platforms (VSCode) to their derivatives (Cursor, Windsurf), but security assumptions don't automatically transfer between differently managed ecosystems.

License-Driven Architecture Decisions: Licensing restrictions that prevent access to Microsoft's marketplace fundamentally alter the security model of these forked IDEs in ways that may not be immediately apparent to developers or even the fork maintainers.

Delayed Response Dynamics: The varied response times from affected companies suggest inconsistent security prioritization in the competitive AI-IDE landscape, where feature development often outpaces security investment.

Registry Fragmentation Risks: The emergence of alternative extension registries (like OpenVSX) without coordinated security governance creates blind spots where malicious packages can infiltrate development workflows.

Protective Measures

For developers using forked VSCode variants, several protective measures are essential:

Manual verification: Always cross-check recommended extensions by directly accessing the OpenVSX registry and confirming publisher legitimacy
Extension audit: Regularly review installed extensions, particularly those automatically recommended by your IDE
Security-first configuration: Consider disabling automatic extension recommendations in favor of manual, verified installation

For the industry, this incident signals the need for:

Fork-aware security auditing processes that specifically check for inherited vulnerabilities in divergent deployment contexts
Registry coordination mechanisms between primary and alternative marketplaces to sync namespace claims
Transparent security disclosure from fork maintainers about how their security model differs from upstream projects
Automated namespace monitoring tools that alert maintainers when recommended extensions are unavailable in their designated registry

The unclaimed namespace vulnerability in VSCode forks represents a paradigm case of modern software supply chain risk—where well-intentioned architectural decisions based on licensing, forking, and ecosystem development inadvertently create security gaps. As the AI-powered IDE landscape continues to evolve at breakneck speed, security cannot remain an inherited afterthought.

The rapid response from some players (Google) and concerning silence from others (Cursor, Windsurf) paints a fragmented security picture in an increasingly critical developer tools segment. What begins as a convenient extension recommendation could end as a sophisticated software supply chain attack, compromising not just individual developers but the integrity of the applications they build.

As we delegate more of our development workflow to AI-assisted tools, we must simultaneously strengthen the human oversight of the underlying systems that make these innovations possible. The forks in our code have created forks in our security responsibility—and bridging these gaps will determine whether the next generation of development tools empowers developers or endangers them.

VSCode Forks Poisoned Fake Extensions in Trusted Tools

Related threat feeds

Daxin Malware Resurfaces in Taiwan Alongside Novel Stupig Backdoor After Decade Long Silence

Mechanics of a Silent Threat

A Race Against Time

Implications for Software Supply Chains

Protective Measures

148 Malicious npm Packages Used to Build a Browser Based DDoS Botnet

Pakistan Law Enforcement Agencies Targeted in Alleged Multi Group Cyber Espionage Operations