This dropped Sunday. If anyone on your team uses Cursor, Windsurf, VSCodium, or any VS Code fork that pulls from the Open VSX marketplace, you need to spend 20 minutes on this today.
Security researchers at Socket published their findings on April 26: 73 fake extensions have been planted on the Open VSX registry, all linked to the same threat actor behind a campaign called GlassWorm. Six of those 73 have already been activated and are delivering malware right now via the normal extension update path.
What Open VSX is and why your team probably has it
Open VSX is the extension marketplace used by VS Code forks — Cursor, Windsurf, VSCodium, and any other IDE that can't legally access Microsoft's official extension store. If your team is using Cursor or Windsurf for AI-assisted coding (and a lot of small dev teams are, because they're genuinely excellent), their extensions are coming from Open VSX.
This matters because the same extensions you know from VS Code — linters, formatters, Git integrations, theme packs — exist as Open VSX listings. Most developers assume they're the same thing. They're not. They're separate submissions by whoever decided to publish there. That gap is exactly what GlassWorm exploits.
The sleeper mechanism — this is the part you need to understand
A normal malicious extension is easy to catch: someone publishes something that immediately does something bad, gets flagged, gets pulled. GlassWorm doesn't work like that.
The 73 extensions discovered this week were published clean. No malware. They are clones of legitimate, popular extensions — same icon, same description, same name, same apparent functionality. Some were sitting there for months. They build up install counts organically. They pass automated scans. Developers install them and they work fine.
Then they get updated.
The threat actor pushes a malicious update through the normal extension update channel. Anyone who has auto-updates enabled — which is the VS Code default — gets the payload without any prompt or warning. The update looks exactly like every other background update your IDE has ever performed.
Of the 73 newly discovered extensions, at least six have already crossed that line and are actively delivering malware. The rest are presumably still in the waiting phase.
What the malware does once activated
This isn't ransomware. It's quieter and, for a small org, potentially worse.
GlassWorm v2 is a credential harvester and persistent access tool. Once active, it targets:
- GitHub and Git credentials — your repo access, deploy keys, personal access tokens stored locally
- NPM tokens — if your developers have NPM publish access, an attacker can push malicious packages to your dependencies
- 49 different cryptocurrency wallets — if your team is anywhere near web3 work, this is obvious; if not, it's still a good signal about the attacker's sophistication and intent
- Hidden VNC server installation — this is the most serious piece. VNC gives the attacker a persistent, graphical, interactive session on your developer's machine. Not just files. The whole screen. Running processes. Open browser sessions. Whatever's on that machine.
The payload retrieval uses obfuscated JavaScript that fetches a VSIX file from a GitHub-hosted location at runtime. That means the extension file itself can look clean on static scan — the malicious code is pulled down at activation, not bundled in.
Why small dev teams are the actual target here
Enterprise development shops have endpoint detection, managed device policies, and usually a curated list of approved extensions. Small teams don't have any of that.
A 5-person development team at a nonprofit, a public sector agency's digital unit, or a small startup has one thing in common: their developers are installing extensions freely, on personal or minimally managed machines, often with full admin access and cloud credentials sitting in environment files.
That's the profile GlassWorm is optimized for. Steal the GitHub token from a developer at a 10-person org and you don't just get their code — you get whatever their CI/CD pipeline has access to. Staging environments. API keys. Customer data stores. The token that deploys to production.
There's also an uncomfortable irony here: many developers use VSCodium specifically because they don't want Microsoft's telemetry. They're the privacy-conscious ones. They're the ones who went out of their way to use an open-source IDE that doesn't phone home. And Open VSX is the marketplace they landed on as a result. The attack is targeting the developer community that took security seriously enough to avoid the official marketplace in the first place.
What to do right now
This isn't theoretical. Six extensions are live and active. Here's the short list:
Audit your team's installed extensions today. Ask every developer using Cursor, Windsurf, or VSCodium to pull up their extension list. For each one, check who published it. Click through to their GitHub — do you see a real organization, or a fresh account with one empty repository named with a random 8-character string? That's the fingerprint Socket identified across this cluster.
Disable automatic extension updates. In VS Code settings, extensions.autoUpdate defaults to true. Set it to false. Extension updates should be deliberate, not silent background events. Right now, the update path is the attack path.
Rotate GitHub tokens and NPM tokens. Revoke any personal access tokens stored locally in ~/.gitconfig, environment files, or IDE keystores and issue fresh ones. If one of your team members has a compromised machine without knowing it, this limits the damage window.
Remove extensions you don't actively use. If nobody remembers why it's installed, remove it. Smaller surface area is a smaller attack surface.
Check for VNC processes if you're worried. On macOS: ps aux | grep -i vnc. On Linux: ps aux | grep vnc. You're looking for something that shouldn't be there.
The persistent campaign behind this
This isn't GlassWorm's first appearance. Socket has been tracking this threat actor since December 2025. Including this new cluster, they've identified over 320 artifacts linked to the campaign across the past four months. The pace is increasing. The December discovery was 24 malicious extensions. The March discovery was a browser extension variant. Now it's 73.
The campaign is methodical. It's not going away. Whoever is running it is investing serious time in building convincing fake publisher identities, maintaining clean extensions while they accumulate installs, and staging activations carefully. That level of patience and operational investment points at a financially motivated actor, not a script kiddie.
The broader lesson: extension marketplaces are supply chains, and most developers don't think about them that way. When you install an extension, you're trusting code that runs inside your IDE with full access to your file system, your environment variables, and your network. That trust should be earned, not assumed.
We help small teams build practical security hygiene around their developer toolchains — not compliance theater, just the stuff that actually stops attacks like this. If you want a quick audit of your team's extension landscape or help tightening up your CI/CD credentials posture, get in touch.