The AI IDEs Inherited VS Code's Recommendation List, Not Its Marketplace: Cursor, Windsurf, Antigravity, and the OpenVSX Namespace Gap

In late November 2025, Koi Security disclosed that Cursor, Windsurf, Google Antigravity, and Trae — the leading AI-coding IDE forks of VS Code — were recommending extensions to their users that did not exist on the extension marketplace those IDEs actually install from. Anyone could claim the missing OpenVSX namespaces and ship code execution to every developer who clicked the recommendation prompt. Koi ran the responsible-disclosure version of the same attack: they claimed the vulnerable namespaces themselves and uploaded placeholder extensions with no functionality. More than 1,000 developers installed them anyway.

---

The structural mistake

When Microsoft built VS Code, the recommended-extensions list and the Microsoft marketplace were the same trust system. The marketplace did publisher verification, marketplace review, and removal-pipeline enforcement. The recommendation list pointed at packages inside that system. A recommendation meant the user was prompted to install something that had passed checks the user didn't have to perform.

When Cursor, Windsurf, Google Antigravity, and Trae forked VS Code, they could not use Microsoft's marketplace. Microsoft's marketplace terms restrict its use to Microsoft's VS Code. The forks adopted OpenVSX — the open-source alternative maintained by the Eclipse Foundation — as their extension registry.

OpenVSX is real, useful, and good infrastructure. It is not the same trust system as Microsoft's marketplace. Different publisher verification, different review process, different namespace-claiming rules. A name reserved on Microsoft's marketplace may be unclaimed on OpenVSX — and the first person to claim it on OpenVSX gets it.

The recommendation list the forks carried over still pointed at Microsoft-marketplace names. Some of those names had OpenVSX equivalents. Some did not. The IDE's recommendation prompt didn't distinguish.

The exploit

The exploit path is two steps.

Step 1. Pick an unclaimed OpenVSX namespace from the forks' recommended-extensions list. Real example from Koi's disclosure: ms-ossdata.vscode-postgresql. The legitimate publisher (Microsoft) had not claimed the equivalent on OpenVSX.

Step 2. Claim the namespace on OpenVSX. Upload an extension. Wait.

Every developer using Cursor, Windsurf, or Antigravity who has the relevant ecosystem installed gets a recommended-installation prompt for the extension, served by the IDE's own UI. The user clicks install. The extension activates. The extension runs as the developer's process — workspace files, environment variables, terminal history, source code, all reachable.

The measurement that matters

Koi's data is the part that turns this from theoretical to operational.

They claimed the vulnerable namespaces themselves and uploaded placeholder extensions — no functionality, no icon, descriptions explicitly stating they were placeholders. More than 1,000 developers installed them. One placeholder labeled "This is a VS Code extension placeholder" still collected over 500 installs.

That number is the measurable demand the IDE's recommendation prompt produces, against literal zero functionality. Multiply by a malware payload and you have the size of the at-risk population.

The recommendation prompt is the load-bearing trust signal here, not the package contents.

Disclosure timeline

• Late November 2025 — Koi Security reports the issue to Cursor, Windsurf, Google Antigravity, and Trae.
• December 1, 2025 — Cursor patches.
• December 26, 2025 — Google Antigravity removes 13 extension recommendations.
• January 1, 2026 — Google marks the issue fixed.
• Windsurf — had not responded as of the public disclosure date.

The timeline is the part to read carefully. The issue is solvable — Cursor's response window from disclosure to patch was about a week. The remaining exposed forks are the ones that have decided this is not a priority for them yet.

What this is, in pattern terms

Cursor, Windsurf, and Antigravity each pitched themselves as "VS Code, but better for AI." What they actually shipped was VS Code's configuration surface — recommendation lists, settings schemas, command palette behaviors — running against a different marketplace, with no reconciliation between the two trust systems.

The inherited configuration looked benign because it always had. The security model that made it benign in Microsoft's hands did not come along for the fork.

This is the same pattern that produced the Codex command-injection bug (a string flowing into execSync inside an AI agent), the MCP STDIO RCE (a config-becomes-command default inherited from a reference SDK), and the Mini Shai-Hulud / Lightning compromise (a postinstall hook inherited from npm semantics). AI tools are shipping at velocity, and they keep inheriting threat models from older primitives — extension marketplaces, command interpolation, install-time hooks — without re-validating those models against the marketing claim of "faster, smarter, AI-first."

The cadence is consistent. Every few weeks, a different layer of the AI stack gets a finding traceable to a primitive that was already considered solved in the pre-AI ecosystem. The IDE-fork extension marketplace is this layer's version.

What to do

If your team uses Cursor, Windsurf, Antigravity, or another VS Code fork

• Audit installed extensions. The same name on Microsoft's marketplace and on OpenVSX is not the same package — the publisher namespace is what matters, not the human-readable name.
• Disable inherited recommendation prompts where the IDE permits it. If the prompt has to stay enabled, train developers that "recommended" is a UI element, not a security claim.
• Pin extensions by publisher and version, not by name. Lock the publisher's identity in your org's allowlist; treat any namespace whose publisher does not appear in your allowlist as untrusted.
• Treat any recommended-but-unverified-publisher extension the way you'd treat an npm package with three downloads and a single maintainer — adversarial until verified.

If you build an IDE fork or a developer tool that consumes a registry

• Re-validate every trust signal you inherited from the upstream. A recommendation list is a trust signal; a configuration default is a trust signal; a settings schema is a trust signal. None of them automatically transfers across marketplaces.
• Decide explicitly whether to support recommendations whose targets do not exist in your registry. The defensible answers are "no, drop them" or "yes, but reconcile with the publisher first." The default-on inheritance answer is the one Koi documented as exploitable.

If you build agents that install extensions on behalf of users

• Add a publisher-verification check between "the user said yes" and "the extension installs." The IDE will not do it for you.
• The recommendation prompt is the trust signal the user clicked through; it is not the trust signal the agent should rely on.

How Rafter helps

Rafter's Code Analysis Engine does not patch a vendor IDE's recommendation pipeline — that's upstream of any code scanner you run on your own codebase. What scanning does address is the analog of the same bug class on your side. If your product ships configuration defaults that point at external resources (registries, marketplaces, package indexes, recommendation lists), the diff that introduces a default pointing at an unclaimed or unverified namespace is exactly where the warning is most useful. Trust signals copied from an upstream are the kind of finding that is invisible to test suites and obvious to a code scanner pointed at the right pattern.

Closing on the inheritance

Cursor, Windsurf, Antigravity, and Trae all inherited a recommendation list designed for a marketplace they do not use. The fix is small — drop the recommendations that don't resolve, reconcile the ones that do, and treat the recommendation prompt as a UX feature rather than a trust mechanism. Three of the four affected vendors implemented it within five weeks of Koi's disclosure. One has not.

The pattern under the headline is bigger than four IDEs. Every AI tool shipping today inherits a stack of older primitives the marketing copy treats as solved. Most of the time, those primitives are solved — for the original tool, in the original context, against the original threat model. The fork doesn't get any of that for free.

Inherit the configuration, and you inherit whoever can claim the namespace next.

Further reading

• A Branch Name as RCE: OpenAI Codex and the GitHub Token It Held — the same shape of inheritance bug at the agent level rather than the IDE level.
• Three Supply Chains, One Trust Relationship — agent runtime, marketplace, and registry as compounding trust relationships.
• PyTorch Lightning, Mini Shai-Hulud, and Malware That Signs Commits as Claude Code — install-time inheritance from package-manager primitives.

Sources

• Koi Security — How We Prevented Cursor, Windsurf & Google Antigravity from Recommending Malware: https://www.koi.ai/blog/how-we-prevented-cursor-windsurf-google-antigravity-from-recommending-malware
• The Hacker News — VS Code Forks Recommend Missing Extensions, Creating Supply Chain Risk in Open VSX: https://thehackernews.com/2026/01/vs-code-forks-recommend-missing.html
• BleepingComputer — VSCode IDE forks expose users to "recommended extension" attacks: https://www.bleepingcomputer.com/news/security/vscode-ide-forks-expose-users-to-recommended-extension-attacks/
• GBHackers — Cursor, Windsurf & Google Antigravity IDEs Linked to Malicious Extension Exposure: https://gbhackers.com/cursor-windsurf-google-antigravity-ides-linked-to-malicious-extension/
• The trust-signal forgery economy
• MCP server security review checklist
• A year of AI developer-tool supply-chain attacks