In July 2025, a Cursor IDE user working in the cryptocurrency industry lost roughly $500,000 after installing an extension called "Solidity Language" — a package that looked, on its listing page, like an ordinary syntax-highlighter for Solidity smart-contract code. It wasn't. According to research from Kaspersky and a subsequent writeup from Snyk, the extension shipped a malicious extension.js file that launched a PowerShell script on install, which then continued exfiltration and hijacked the victim's crypto assets. The extension had accumulated more than 50,000 downloads before it was pulled. What makes the case notable isn't just the payload — it's the distribution path. The package was published to Open VSX, the unofficial, community-run extension registry that VS Code forks like Cursor, Windsurf, and others pull from because they can't legally use Microsoft's official Marketplace. Microsoft's own marketplace team reportedly caught and removed the same or a similar submission within seconds; the Open VSX copy lingered long enough to spread widely. This piece walks through what happened, why extension marketplaces are a soft spot in the supply chain, and what teams can actually do to verify what they're installing before it runs with full IDE-level file-system and network access.
What actually happened in the Cursor extension attack?
An extension named "Solidity Language" was published to Open VSX, positioned to catch developers working on smart contracts — a group disproportionately likely to have crypto wallets, private keys, or exchange credentials sitting on the same machine. Once installed, the extension's extension.js executed a PowerShell script that Kaspersky's research ties to further exfiltration and cryptocurrency-asset hijacking. Snyk's reporting confirmed at least one victim, a crypto-industry developer, who lost approximately $500,000. The extension reached 50,000+ downloads before removal, and was pulled from the official VS Code Marketplace within seconds of publication — evidence that Microsoft's automated review works when the extension goes through Microsoft's own pipeline. Open VSX, run independently, did not catch it as quickly, and no public IOCs, wallet addresses, or confirmation of additional victims have been published as of this writing.
Why do VS Code forks even use a different marketplace?
Microsoft's Visual Studio Code Marketplace has terms of service that restrict its use to Microsoft's own VS Code product — forks like Cursor, Gitpod, Theia, and VSCodium are not permitted to point at it directly. Open VSX exists specifically to fill that gap: it's an open-source registry, originally seeded by the Eclipse Foundation, that any VS Code-compatible editor can query. That's a reasonable and even necessary piece of infrastructure for an ecosystem of forks to exist at all — but it means the review rigor, takedown speed, and reputation signals a developer has come to associate with "the VS Code Marketplace" don't automatically carry over. A developer typing an extension name into Cursor's built-in search bar has no obvious visual cue telling them which registry is serving the result, or what vetting — if any — that registry applied before listing it.
What made this extension convincing enough to install?
The extension traded on category trust rather than brand trust. There's no dominant, universally recognized "official" Solidity extension the way there might be for, say, Python or ESLint tooling, so a developer searching for Solidity syntax support has fewer prior expectations to violate. A plausible name, a plausible description, and a functioning (or partially functioning) syntax highlighter is often enough to clear the bar of "looks legitimate" for a quick install. This mirrors a pattern seen repeatedly in the open package ecosystems Safeguard tracks daily — npm and PyPI typosquats succeed for the same reason: attackers pick a niche with real demand and thin competition, then rely on developers moving fast and not auditing every dependency's source before use. An IDE extension is arguably worse ground for an attacker to exploit than a library dependency, because it runs with the full privileges of the editor process itself, not sandboxed to a project's dependency tree.
How is an extension different from a compromised npm package?
A malicious npm or PyPI package is usually constrained, at least somewhat, by what the runtime and CI environment exposes — though install scripts already grant broad execution rights. An IDE extension is a different threat class: it runs continuously, with access to every file the editor has open across every project, environment variables, integrated terminals, and any credentials cached in the IDE's own storage. Cursor and other AI-assisted forks additionally integrate model context and agentic file-editing features, meaning a compromised extension sits adjacent to whatever automation the IDE performs. Extensions also auto-update by default in most editors, so a "trust but verify" review at install time doesn't cover a maintainer account takeover that ships a malicious version six months later — the same after-the-fact-versioning problem that has hit legitimate-seeming open-source packages before.
What should teams actually do about it?
Snyk's own recommendation is the right starting point: treat extension installs the same way you'd treat adding a new dependency — verify the publisher's identity and history, check whether source is public and matches the published bundle, and be skeptical of registries without Microsoft's review pipeline behind them. Concretely, that means restricting Open VSX (and other third-party registries) via IDE settings or an allowlist where the organization doesn't need fork-specific tooling, pinning extension versions instead of accepting silent auto-updates on developer machines handling sensitive credentials, and treating any extension requesting shell or network access as high-risk regardless of its stated purpose. Safeguard's own package and container scanning already applies this kind of behavioral scrutiny — what does an install script execute, and where does the resulting process phone home — to ecosystems like npm, PyPI, and container registries. IDE extension marketplaces are a related but currently distinct surface, and the same lens is the right one to apply to them, whether or not a given registry offers that scanning natively today.