A single inherited config file put millions of developers at risk across every major AI IDE

We discovered that the most popular AI IDEs were officially recommending extensions that didn't exist, namespaces anyone could claim and upload malware to. So we claimed them first.

The AI IDE Gold Rush Has a Blind Spot

Cursor, Windsurf, Google Antigravity, Trae: these are the hottest tools in software development right now. Cursor alone has over a million daily active users and a $9.9 billion valuation. Windsurf hit a million users within months of launch. Google Antigravity launched just weeks ago, backed by the $2.4 billion acquisition of Windsurf's team and technology.

They all have something in common: they're all forked from VSCode.

And they all have a problem: they can't use Microsoft's extension marketplace. The license explicitly prohibits non-Microsoft products from accessing it. So they use OpenVSX, the open-source alternative maintained by the Eclipse Foundation.

But when they forked VSCode, they inherited its extension recommendation list, a list that points to extensions on Microsoft's marketplace. Extensions that don't all exist on OpenVSX.

The Problem: Recommending Extensions That Don't Exist

These IDEs ship with hardcoded official proactive recommendations. Not search results. Not suggestions you asked for. The IDE actively tells users: "You should install this."

There are two types of recommendations:

File-based recommendations: Open a file like azure-pipelines.yaml, and a toast notification pops up recommending the Azure Pipelines extension.

Software-based recommendations: Have PostgreSQL installed on your machine? The IDE automatically recommends a PostgreSQL extension in your sidebar, without you ever searching for one.

The problem: these recommended extensions didn't exist on OpenVSX. The namespaces were unclaimed. Anyone could register them and upload whatever they wanted.

What Could Have Happened

Picture this: An attacker registers ms-ossdata.vscode-postgresql on OpenVSX. Uploads a malicious extension.

Now every developer with PostgreSQL installed opens Cursor, Windsurf, or Antigravity and sees: "Recommended: PostgreSQL extension." They trust it, their IDE recommended it. They click install.

The extension runs with full system access. SSH keys, AWS credentials, source code, all exfiltrated. No phishing required. No suspicious download. Just a normal day using your IDE.

Our placeholder PostgreSQL extension, with no icon, clearly stating "This is a VS Code extension placeholder", has over 500 installs. People are installing it anyway, because their IDE told them to.

What We Did

We claimed the vulnerable namespaces ourselves and uploaded placeholder extensions to prevent malicious actors from getting there first.

Extensions we secured:

• ms-ossdata.vscode-postgresql: triggered when PostgreSQL is installed on machine
• ms-azure-devops.azure-pipelines: triggered when opening azure-pipelines.yaml
• msazurermtools.azurerm-vscode-tools: triggered when opening azuredeploy.json
• usqlextpublisher.usql-vscode-ext: triggered when opening *.usql files
• cake-build.cake-vscode: triggered when opening build.cake
• pkosta2005.heroku-command: triggered when Heroku CLI is installed on machine

Over 1,000 developers installed our placeholder extensions, extensions with no functionality, no icon, and a description explicitly stating they're placeholders. They installed them because their IDE recommended them. That's how much users trust these recommendations.

We then collaborated with the Eclipse Foundation (which operates OpenVSX) to verify all remaining referenced namespaces and extensions in these IDEs' configs are safe, and remove any non-official contributors from the namespaces. 

Disclosure

• Nov 23, 2025: Reported to Google
• Nov 24, 2025: Reported to Cursor (security-reports@cursor.com)
• Nov 24, 2025: Reported to Windsurf (security@windsurf.com)
• Nov 25, 2025: Google closes report as "Won't Fix (Infeasible)"
• Nov 25, 2025: We clarify the attack vector: no account compromise needed
• Nov 25, 2025: Google closes report again as "Won't Fix"
• Nov 25, 2025: We clarify again: attacker uses their own account, all users affected
• Nov 26, 2025: Google reopens and accepts the vulnerability
• Nov 26, 2025: Contacted OpenVSX to verify remaining namespaces
  
• Dec 1, 2025: Cursor acknowledged and fixed the issue
• Dec 26, 2025: Google ships partial fix (13 extensions removed)
• Dec 26, 2025: We flag remaining vulnerable extensions still in config
• Jan 1, 2026: Google marks as fixed
• Today: Public disclosure

Windsurf never responded.

The Eclipse Foundation, which runs OpenVSX, was a pleasure to work with. They responded quickly, verified the namespaces we flagged, and proactively took further security measures across the registry. Because of their collaboration, we can responsibly disclose without waiting for vendors who haven't responded.

Final Thoughts

Extension marketplaces are the new software supply chain, and this research shows how easily they can be exploited.

We built Koi to catch exactly these kinds of threats: attackers exploiting the gaps in extension marketplace defenses. While your IDE's recommendations might be compromised, our risk engine watches what extensions actually do during installation: network requests, file system access, script execution, behavioral patterns that reveal malicious intent regardless of how the code got there.

Trusted by Fortune 50 organizations and some of the largest tech companies in the world, Koi helps security teams gain visibility and governance over the third-party code flowing into their environments.

Book a demo to see how our agentic AI risk engine catches threats that slip past traditional defenses.

Stay safe out there.

‍