AI-Powered Code Editors Could Have Become Malware Delivery Machines: Here's What Happened

If you’re a developer using AI-powered code editors like Cursor, Windsurf, or Google Antigravity, you might want to pay attention to this one. Security researchers have uncovered a vulnerability that could have turned your trusted IDE’s extension recommendations into a malware delivery system. The good news? They caught it before the bad guys did.

The Problem With Forking VSCode

Here’s the thing about modern AI coding assistants: they’re basically souped-up versions of Microsoft’s Visual Studio Code. Cursor, Windsurf, Google Antigravity, Trae—they all share the same DNA. They’ve been forked from VSCode to add AI superpowers that help developers write code faster.

But there’s a catch. These forks can’t actually use Microsoft’s official Visual Studio Marketplace. The licensing terms explicitly prohibit non-Microsoft products from accessing it. So instead, they rely on OpenVSX, an open-source alternative maintained by the Eclipse Foundation.

When these companies forked VSCode, they inherited something they probably shouldn’t have: a hardcoded list of extension recommendations pointing to Microsoft’s marketplace. These recommendations were baked right into the configuration files, and they kept triggering even though the IDEs were now connected to a completely different extension store.

How the Attack Would Have Worked

Picture this scenario: You’re a developer with PostgreSQL installed on your machine. You fire up Cursor, and a friendly little notification pops up: “Recommended: PostgreSQL extension.” Seems legit, right? Your IDE is trying to be helpful.

But here’s where it gets interesting. That recommended extension—the one your trusted IDE is actively pushing—didn’t actually exist in OpenVSX. The namespace was completely unclaimed. Anyone could have registered it.

Security researchers at Koi Security spotted this gap and realized the implications immediately. A malicious actor could simply register these phantom namespaces, upload extensions packed with malware, and wait for developers to click “Install” when their IDE made the recommendation.

No phishing emails required. No suspicious download links. Just a normal day using your coding tool.

There were two types of these phantom recommendations floating around:

File-based triggers: Open a file like azure-pipelines.yaml, and the IDE would pop up a toast notification recommending the Azure Pipelines extension—an extension that didn’t exist where the IDE was looking.

Software-based detection: The IDE would scan your system, detect something like PostgreSQL or the Heroku CLI, and suggest corresponding extensions that were equally non-existent in OpenVSX.

The Researchers Who Saved the Day

Koi Security researcher Oren Yomtov and his team didn’t just discover this vulnerability—they did something about it. Rather than wait for someone with bad intentions to claim these dangerous namespaces, the researchers registered them first.

They uploaded placeholder extensions with no functionality whatsoever. These placeholders explicitly stated they were just blocking potential attackers. Despite having no icons, no features, and a clear disclaimer that they were placeholders, hundreds of developers installed them anyway.

Why? Because their IDE told them to. That’s how powerful these recommendation systems are, and exactly why this vulnerability was so dangerous.

The Response Timeline: A Mixed Bag

Once Koi Security identified the problem in late November 2025, they reached out to the affected vendors. The responses varied considerably.

Cursor moved quickly, implementing a fix on December 1st, 2025. They acknowledged the issue and patched it within days of being notified.

Google initially dismissed the report as “infeasible” but eventually came around. They removed 13 vulnerable extension recommendations from their Antigravity IDE on December 26th and marked the issue as fully resolved by January 1st, 2026.

Windsurf had not responded to the disclosure at the time of the public report. That silence is concerning for developers who rely on the platform.

The Eclipse Foundation, which operates OpenVSX, proved to be particularly collaborative. They worked with the researchers to verify all remaining referenced namespaces, remove non-official contributors from sensitive areas, and implement broader registry-level safeguards.

Why This Matters Beyond Just Extensions

This incident exposes a fundamental problem in how we think about forked software. When companies build on top of existing platforms, they inherit more than just code—they inherit trust assumptions that may not apply in their new context.

VSCode’s extension recommendations make perfect sense when pointing to Microsoft’s carefully curated marketplace. Those namespaces are occupied by legitimate publishers, and Microsoft has processes in place to verify them. But when you point those same recommendations at an open registry where anyone can claim any namespace? That’s a completely different security model.

The AI coding tool market is exploding right now. Developers are gravitating toward these enhanced editors because they genuinely improve productivity. But this rapid adoption also means less scrutiny of the underlying architecture. Speed matters in a competitive market, but so does security hygiene.

What Developers Should Do Right Now

If you’re using any VSCode fork, there are some practical steps you can take to protect yourself.

First, treat extension recommendations as suggestions, not commands. Just because your IDE says you should install something doesn’t mean you should do it blindly. Take a moment to verify the extension exists in the proper registry and comes from a legitimate publisher.

Second, check the publisher’s verification status. On OpenVSX, look for signs that the extension comes from the organization it claims to represent. Zero download history, newly created namespaces, or missing verification badges are all red flags.

Third, review what you’ve already installed. Open your extensions panel and look for anything that seems out of place—extensions with no icons, strange publisher names, or functionality that doesn’t match what you expected when you installed it.

For organizations, consider implementing extension allowlists. Rather than letting developers install whatever their IDE suggests, maintain a curated list of approved extensions that have been vetted by your security team.

The Bigger Picture: Extension Marketplaces Are Attack Vectors

This isn’t an isolated incident. Over the past year, we’ve seen multiple security issues related to VSCode extensions and the OpenVSX ecosystem. The GlassWorm campaign targeted macOS developers through malicious extensions. Threat actors have published extensions with tens of thousands of fake downloads for “social proof.” Typosquatting attacks continue to pop up regularly.

Extension marketplaces have become the new software supply chain, and they’re increasingly in the crosshairs of attackers. The extensions we install run with significant privileges on our development machines. They can access our code, our credentials, our SSH keys, our cloud configurations—basically everything that matters.

The security community is paying attention, but so are the attackers. Microsoft has announced plans to add secret scanning capabilities to block extensions with verified secrets and notify developers when issues are detected. The Eclipse Foundation is tightening controls on OpenVSX. But the fundamental tension remains: developers want frictionless access to tools that enhance their workflow, while security demands friction in the form of verification and vetting.

No Evidence of Exploitation—This Time

The silver lining here is that there’s no public evidence anyone actually exploited this vulnerability before Koi Security intervened. The researchers moved fast enough to claim the dangerous namespaces before malicious actors could do so.

But that’s partly luck. This gap existed for an unknown period of time while these AI-powered IDEs grew their user bases into the millions. If a sophisticated threat actor had spotted it first, they could have compromised countless development environments without raising any alarms.

The incident serves as a reminder that security research isn’t just about finding bugs after they’re exploited. Proactive discovery and responsible disclosure can genuinely prevent harm. The Koi Security team didn’t just write a report—they took concrete action to protect developers by registering those vulnerable namespaces themselves.

Moving Forward

The vendors involved have largely addressed the immediate issue. Cursor and Google have patched their IDEs. The Eclipse Foundation has strengthened OpenVSX. The phantom namespaces are now occupied by harmless placeholders.

But the broader lesson here is about trust. In modern software development, we place enormous trust in our tools, our package managers, our extension stores. That trust needs to be earned and continuously verified, not assumed by inheritance.

As AI-powered development tools continue to evolve and new forks emerge, the security community will need to remain vigilant about these kinds of trust boundary mismatches. The next vulnerability might not be caught in time.

For now, keep your extensions minimal, verify before you install, and remember: just because your IDE recommends something doesn’t mean it’s safe.

---

Source: BleepingComputer