Community Post Warns Cursor Extension IDs Can Resolve to Different Publishers Than VS Code

A community post on dev.to contends that teams migrating from VS Code to Cursor may not be installing the extensions they believe they are. The author's core assertion is that Cursor has no access to Microsoft's extension marketplace, with the result that a publisher.extension identifier developers trust in VS Code can resolve to a different publisher delivering different code. The piece presents this as an unexamined blind spot rather than a disclosed incident at any named organization, and it is an author claim on a community platform, not an independently verified finding.

A registry swap is the mechanism outlined in the post. The author claims that Microsoft's marketplace terms restrict that marketplace to VS Code alone, so forks are contractually excluded. Consequently, extension search and downloads in Cursor are routed through its own proxy, which sits in front of Open VSX, the open registry. Cursor's own documentation, the post notes, admits the result: on Open VSX, a given publisher.extension name might refer to different code or a different publisher compared with Microsoft's marketplace.

The author adds that for certain popular extensions that never reached Open VSX, Cursor ships its own replacement builds under an "Anysphere" publisher name. That detail matters for auditing, because an installed extension whose publisher reads Anysphere is not necessarily the original vendor's build. The post does not enumerate which extensions receive this treatment, leaving the scope of substitution open.

Version drift forms the second half of the argument. Even where the publisher matches across registries, the author says Open VSX copies are published separately, nothing guarantees parity, and there is no lockfile or pinning mechanism for IDE extensions. Auto-update is described as enabled by default, so the artifact a team vetted and the artifact running a month later are not necessarily identical.

As evidence that drift has consequences, the post cites an incident from July 2025 in which a malicious "Solidity Language" extension on Open VSX executed a PowerShell script during installation. Per the author, it accumulated 50,000 downloads before removal, and one Cursor user in the crypto industry lost roughly $500,000, a figure credited to Kaspersky research. The post also reports that Microsoft removed the same or a similar submission from its own marketplace within seconds, while the Open VSX copy lingered. These are the author's renderings of third-party findings; the supplied evidence does not include the underlying Kaspersky research.

The post further references OX Security findings: CVE-2025-65717 in Live Server with a CVSS score of 9.1, CVE-2025-65715 in Code Runner, and CVE-2025-65716 in Markdown Preview Enhanced. According to the author, every published version of those three is affected and the maintainers never responded to disclosure. The practical consequence drawn is that if an editor serves an older build, no patched version is waiting on the other side of an update.

Two Cursor defaults are pinpointed as amplifiers. In Cursor, Workspace Trust is shipped disabled, the author says, and its Marketplace Install Cooldown defaults to 0; when set, that cooldown delays installs until a version has been available for a specified number of hours. Given those defaults, the post contends, the moment auto-update triggers, a malicious update pushed to Open VSX can reach every developer within an organization.

The remedy proposed is an audit the author says takes an afternoon. It suggests baselining with code --list-extensions --show-versions, comparing that against cursor --list-extensions --show-versions, and cross-checking the on-disk extensions folder, whose directory names embed versions. It then suggests querying the Open VSX API per extension to compare version and publisher against the Microsoft listing.

The author lists conditions to flag: a publisher differing between registries, an installed version trailing the Microsoft listing by more than a minor release, a publisher showing as Anysphere where the original vendor was expected, or an extension installed but absent from Open VSX entirely. Each is a triage heuristic rather than a confirmed compromise indicator, and the post offers no data on how often any of them occurs.

The author's stated position is that malware scanning at the proxy does not address this problem, because a scanner will pass extensions that are clean but stale, or that come from a publisher the team never vetted. The post argues an allowlist is the single highest-value control here, and calls a cooldown under 72 hours for anything touching credentials negligence dressed as convenience. That is an opinion, presented as such.

Concrete steps are recommended: compare the two extension lists and assign each discrepancy a named owner; make AllowedExtensions a team-wide default-deny setting via MDM or the team dashboard; configure the Marketplace Install Cooldown to no less than 72 hours and enable Open VSX signature verification, which, the author notes, establishes origin rather than intent; and, until replacements are chosen, treat any installed version of Live Server, Code Runner, or Markdown Preview Enhanced as affected.

For freelancers, designers and developers working across client environments, the practical implication is that an extension inventory becomes part of onboarding and handoff. If a contractor moves a project between VS Code and Cursor, or joins a client's Cursor workspace, the extension set is not guaranteed to be equivalent, and the post's diff commands are a low-cost way to surface mismatches before they matter. Editorial interpretation: treating the extension list as configuration to be reviewed, rather than as ambient tooling, is the transferable habit here.

The post's own recommendations carry tradeoffs. A default-deny allowlist reduces exposure but adds friction whenever a developer wants a new tool, and it requires someone to own the list. A 72-hour cooldown delays legitimate security patches as well as malicious ones. Signature verification confirms who published an artifact, not whether the artifact is safe, a limitation the author states directly.

Several things remain unknown from the supplied evidence. The post does not quantify how common publisher swaps or Anysphere substitutions are in practice; it closes by asking readers what they found, which indicates the author lacks that data. The Kaspersky loss figure and the Microsoft takedown timing are relayed secondhand. The OX Security CVE details and the claim that maintainers did not respond are likewise reported rather than shown. The post also does not state which Cursor versions or dates the described defaults apply to.

The most defensible reading is narrow. A community author has documented a registry architecture difference between VS Code and Cursor, cited a specific July 2025 malicious extension and three named CVEs as evidence that drift has consequences, and published a repeatable audit procedure. The audit commands and the flagging criteria are the actionable part; the incident narratives and dollar figures should be treated as attributed claims pending the primary sources.

For teams that want to act, the post's own sequencing is sensible: run the diff first, then argue about policy. The author explicitly invites readers to report what their diffs turned up, a reasonable acknowledgment that the prevalence question is still open. Until that data exists, the case for an allowlist rests on the mechanism and the cited incidents rather than on measured frequency.