DEV Community

Jason Miller
Jason Miller

Posted on Originally published at axeploit.com

Same Extension ID, Different Publisher: What Actually Installs When Your Team Moves to Cursor

#supplychain #secrets #aiagents

Nobody on your team checked which extension versions landed when they moved from VS Code to Cursor. They searched the same IDs, clicked install, and went back to work. That is the blind spot: Cursor can't use Microsoft's extension marketplace at all, so the ID your developers trust can resolve to a different publisher shipping different code.

The registry swap nobody announced

Microsoft's marketplace terms restrict it to VS Code itself. Forks like Cursor are locked out by contract, so Cursor routes extension search and downloads through its own proxy in front of Open VSX, the open registry. Cursor's documentation is unusually honest about what that means: the same publisher.extension name can point to a different publisher or different code on Open VSX than on Microsoft's marketplace. For some popular extensions that never made it to Open VSX, Cursor ships its own "Anysphere" replacement builds.

Even when the publisher matches, versions drift. Open VSX copies are published separately, nothing guarantees parity, and there's no lockfile or pinning mechanism for IDE extensions. Auto-update is on by default, so the artifact you vetted and the artifact running next month are not the same thing.

Drift has already been exploited

In July 2025 a malicious "Solidity Language" extension on Open VSX ran a PowerShell script on install. It passed 50,000 downloads before removal, and one crypto-industry Cursor user lost roughly $500,000, per Kaspersky research. Microsoft reportedly killed the same or a similar submission on its own marketplace within seconds. The Open VSX copy lingered.

Then there are the OX Security findings: CVE-2025-65717 in Live Server (CVSS 9.1), CVE-2025-65715 in Code Runner, CVE-2025-65716 in Markdown Preview Enhanced. Every published version of those three is affected, and OX reports the maintainers never responded to disclosure. If your editor serves an older build, there's no patched version waiting on the other side of an update.

Cursor also ships with Workspace Trust disabled, and its Marketplace Install Cooldown, which delays installs until a version has soaked for a set number of hours, defaults to 0. A malicious update pushed to Open VSX can reach every developer in your org the moment auto-update fires.

Audit the installed set this week

This takes an afternoon. Do it before arguing about policy.

# Baseline from VS Code
code --list-extensions --show-versions

# What Cursor actually installed
cursor --list-extensions --show-versions

# Cross-check on disk (folder names embed versions)
ls ~/.cursor/extensions

# Per extension, compare Open VSX against the Microsoft listing
curl -s "https://open-vsx.org/api/<publisher>/<name>" \
  | jq '{version, publisher: .publishedBy.loginName}'
Enter fullscreen mode Exit fullscreen mode

Flag anything where the publisher differs between registries, the installed version trails the Microsoft listing by more than a minor release, the publisher shows as Anysphere where you expected the original vendor, or the extension is installed but absent from Open VSX entirely.

My position: malware scanning at the proxy doesn't touch this problem, because a scanner passes extensions that are clean but stale, or from a publisher you never vetted. An allowlist is the single highest-value control here, and a cooldown under 72 hours for anything touching credentials is negligence dressed as convenience.

Take this week:

  • Diff code --list-extensions against cursor --list-extensions and give every mismatch a named owner.
  • Enable AllowedExtensions team-wide, default-deny, via the team dashboard or MDM.
  • Set the Marketplace Install Cooldown to at least 72 hours and turn on Open VSX signature verification (it proves origin, not intent).
  • Treat any installed Live Server, Code Runner, or Markdown Preview Enhanced version as affected and decide what replaces them.

If you've run this diff on a real team, what did you find? I'm curious how common publisher swaps and Anysphere substitutions actually are in the wild.

Longer writeup if you want the full argument: https://axeploit.com/blog/same-extension-id-different-code-what-actually-installs-when-your-team

Top comments (0)