In June 2025, a Russian blockchain developer installed what looked like the standard "Solidity Language" syntax-highlighting extension in Cursor, the AI-powered fork of VS Code. It wasn't the real one. Kaspersky's Securelist team, along with Snyk and BleepingComputer, documented the resulting infection: the fake package, published to the Open VSX Registry on June 15, 2025 — timed to outrank the legitimate extension's May 30 update and land at position #4 in search results while the genuine package sat at #8 — contained no real Solidity tooling at all. Instead it silently installed ScreenConnect remote-access software, which pulled down a Quasar backdoor, which in turn deployed the PureLogs infostealer to harvest browser data, email credentials, and crypto wallet seed phrases. Before Open VSX pulled it on July 2, 2025, the extension had been downloaded an estimated 50,000 to 54,000+ times; after takedown, a republished copy inflated its install counter to roughly 2 million against the real extension's 61,000. The victim lost $500,000 in cryptocurrency despite running a freshly installed OS and scanning the file with malware tools first. This post examines why the marketplace model let it happen, and what actually would have stopped it.
What made Open VSX a softer target than the VS Code Marketplace?
Open VSX exists because Microsoft's VS Code Marketplace operates under proprietary terms that forks like Cursor, VSCodium, and Gitpod aren't licensed to use — so the Eclipse Foundation-backed Open VSX Registry became the default alternative for any editor that isn't VS Code itself. That necessity comes with a tradeoff: Open VSX's publishing model has historically been more permissive about namespace claims and review depth than Microsoft's marketplace, which runs automated and manual verification against known-malicious signatures before an extension goes live. Researchers covering the incident — including Snyk's and BleepingComputer's writeups — pointed to this gap directly: an attacker could register a plausible publisher identity, upload a functional-looking clone, and start competing in search rankings almost immediately. The same infrastructure behind the fake Solidity extension was later linked to a malicious npm package named "solsafe" and several other VS Code/Cursor extensions, including ones named "solaibot" and "among-eth," suggesting a repeatable operation rather than a one-off.
Why did download counts and search rank fail as trust signals?
Download counts and search position are the two signals most developers actually look at before installing an extension, and both were directly manipulated in this case. The attacker's publish timing pushed the fake package above the legitimate one in search results before a single real user had vetted it, and after Open VSX removed the original malicious listing, a republished version showed an inflated 2 million installs — more than 30 times the real extension's genuine count of 61,000. A metric that can be set by the uploader rather than earned through independent verification isn't a trust signal at all; it's a self-reported number with no cryptographic or third-party backing. This mirrors a pattern security researchers have flagged across npm and PyPI for years: install counts and star counts are trivially gameable and should never be the sole basis for deciding whether to run someone else's code inside your editor, which — unlike a sandboxed browser tab — typically has full filesystem and shell access.
How does an AI-assisted IDE change the blast radius of a malicious extension?
AI-powered IDEs like Cursor run extensions with the same privileges VS Code always granted — filesystem access, terminal execution, network calls — but developers using them are often moving faster and reviewing less, because the pitch of these tools is speed. A malicious extension doesn't need to exploit a vulnerability; the VS Code extension API itself allows arbitrary Node.js code to run on activation, which is exactly what let the fake Solidity package drop ScreenConnect without triggering any unusual permission prompt. For a blockchain developer specifically, the local environment often contains wallet files, .env secrets, and browser sessions with exchange or DeFi accounts logged in — precisely what the PureLogs infostealer was built to harvest, per Snyk's and BleepingComputer's analysis of the payload. The extension didn't need to break out of a sandbox; it was never in one.
What does effective extension vetting actually look like?
Effective vetting starts with verifying publisher identity and provenance rather than trusting a listing's name or description. Before installing, check whether the publisher account has a history of other legitimate extensions, whether the extension's source repository is linked and matches what it claims to do, and whether that repository has real commit history rather than a single bulk upload timed to look established. For any extension touching credentials, blockchain tooling, or financial data, cross-reference it against the official project's own documentation for the exact, correct extension identifier — not just a search result. Treat identical-looking clones with slightly different publisher names as a decisive red flag, the same way you'd treat a typosquatted domain. None of this is exotic advice; it's the same provenance discipline security teams already apply to open-source package dependencies, just applied to the editor itself.
How Safeguard Helps
Safeguard's own IDE extension is distributed through Open VSX for Cursor specifically — the same channel this incident abused — which is exactly why its inline Package Firewall checks matter here: as you type a dependency into a manifest, Safeguard flags typosquats (a name one or two edits from a known package), namespace confusion (a scoped package shadowing a trusted unscoped name), and known-malicious package names before you ever run an install. By default this runs as an offline heuristic entirely client-side; enabling safeguard.packageFirewallUseBackend (which requires being logged in) upgrades those verdicts to backend-verified checks against Safeguard's current threat intelligence. That's a meaningful layer against name-squatted dependencies pulled into your project — but it doesn't replace verifying the IDE extensions themselves, since Package Firewall scans manifest entries, not the marketplace listing you click "Install" on. The lesson from this incident is the same one that applies to any software supply chain: no single control is a silver bullet, and provenance checks belong at every layer, including the one running inside your editor.