Popular AI-powered integrated development environment solutions, such as Cursor, Windsurf, Google Antigravity, and Trae, recommend extensions that are non-existent in the OpenVSX registry, allowing threat actors to claim the namespace and upload malicious extensions.
These AI-assisted IDEs are forked from Microsoft VSCode, but cannot use the extensions in the official store due to licensing restrictions. Instead, they are supported by OpenVSX, an open-source marketplace alternative for VSCode-compatible extensions.
As a result of forking, the IDEs inherit the list of officially recommended extensions, hardcoded in the configuration files, which point to Microsoft’s Visual Studio Marketplace.
These recommendations come in two forms: one file-based, triggered when opening a file such as azure-pipelines.yaml, and recommends the Azure Pipelines extension; the other is software-based, occurring when detecting that PostgreSQL is installed on the developer’s system and suggesting a PostgreSQL extension.
source: Koi
However, not all of the recommended extensions exist on OpenVSX, so the corresponding publisher namespaces are unclaimed.
Researchers at supply-chain security company Koi say that a threat actor could take advantage of users’ trust in app recommendations and register the unclaimed namespaces to push malware.
The researchers reported the issue to Google, Windsurf, and Cursor in late November 2025. Google reacted by removing 13 extension recommendations from its IDE on December 26, but Cursor and Windsurf have not responded yet.
Meanwhile, Koi researchers claimed the namespaces of the following extensions to prevent malicious exploitation:
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 researchers uploaded non-functional placeholder extensions that offer no real functionality but still block a supply-chain attack.
Additionally, they have coordinated with Eclipse Foundation, the operator of OpenVSX, to verify the remaining referenced namespaces, remove non-official contributors, and apply broader registry-level safeguards.
At this time, there’s no indication that malicious actors have exploited this security gap before Koi researchers’ discovery and action.
Users of forked IDEs are advised to always verify extension recommendations by manually accessing the OpenVSX registry and checking that they come from a reputable publisher.
Whether you’re cleaning up old keys or setting guardrails for AI-generated code, this guide helps your team build securely from the start.
Get the cheat sheet and take the guesswork out of secrets management.
