Over 70 cloned extensions on Open VSX are now confirmed to be part of a coordinated malware campaign distributing the GlassWorm backdoor.
Key Takeaways
- 70+ cloned extensions in the Open VSX registry mimic legitimate developer tools but contain malicious payloads.
- The malware, named GlassWorm, acts as a sleeper agent, remaining dormant until triggered by remote command.
- Unlike typical supply-chain attacks, these clones don’t alter original code—they’re standalone fakes hosted under slightly altered publisher names.
- Open VSX, the open-source alternative to Microsoft’s VS Code marketplace, lacks the same level of automated scanning and manual curation.
- Victims gain no immediate indication of compromise—the malware waits, sometimes weeks or months, before activation.
The Clone Zone
It’s not a typo. Not a glitch. There are 70 separate extension listings on Open VSX that are pixel-for-pixel duplicates of real tools—except for one line of obfuscated JavaScript buried in a minified file. These aren’t compromised updates. They’re full replicas uploaded by actors who’ve studied how developers search, trust, and install.
They copy names like “Live Server,” “Python,” and “Error Lens.” But the publisher isn’t “Ritwick Dey” or “Microsoft.” It’s “RitwickDev” or “Micros0ft.” Close enough to slip past a tired eye after a 12-hour debugging sprint. One clone of the “Thunder Client” extension—normally a REST API tester—was downloaded over 12,000 times before being yanked.
That’s the trap: Open VSX doesn’t enforce the same identity verification as Microsoft’s Visual Studio Code Marketplace. No two-factor enforcement. No verified badge system. No automated binary scanning. If you can generate a valid manifest, you can publish. And that’s exactly what attackers did—scaling not through compromise, but through mimicry.
How GlassWorm Sleeps
The malware inside these extensions isn’t loud. It doesn’t phone home on install. It doesn’t exfiltrate keystrokes or scrape environment variables. Instead, it waits.
GlassWorm’s payload is triggered by a specific HTTP request to a hardcoded domain—something that could be sent weeks after infection. When activated, it opens a reverse shell, giving attackers full control over the developer’s machine. At that point, they can steal SSH keys, hijack CI/CD pipelines, or move laterally into private repositories.
Because the malicious code isn’t active during the initial scan period, static analysis tools often miss it. Sandboxed execution environments? Bypassed. The extension renders its UI, works as advertised, and earns trust. The backdoor sits idle—like a landmine buried under fresh snow.
Why Open VSX Is the Soft Underbelly
Open VSX exists to avoid vendor lock-in. It’s maintained by the Eclipse Foundation and used by VSCodium, Gitpod, and other open alternatives to VS Code. But independence comes at a cost: no centralized security gatekeeping.
Microsoft scans every extension in its marketplace using automated tools and human reviewers. Open VSX does neither at scale. Its reliance on community moderation means malicious uploads can linger for days—or longer—if no one files a report.
And most developers don’t. They install an extension, it works, they move on. The attack surface isn’t just technical. It’s behavioral. We’re trained to trust the first result in the sidebar. We assume the platform filtered the fakes. But Open VSX never made that promise.
The Publisher Impersonation Playbook
What makes this campaign different from past extension-based attacks isn’t the malware—it’s the distribution strategy. Instead of hijacking a real publisher’s account or submitting malicious updates, the attackers created entirely new identities designed to fool autocomplete and memory.
- “Shan.code-settings-sync” becomes “ShanCodes.code-settings-sync”
- “ms-python.python” becomes “ms-python-dev.python”
- “bradlc.vscode-tailwindcss” becomes “bradlcx.vscode-tailwindcss”
These aren’t random. They follow a pattern: slight misspellings, added prefixes, domain-like variations. Some even reuse actual publisher IDs pulled from public GitHub profiles, then register similar handles on Open VSX.
The goal isn’t to trick the platform. It’s to trick you—the developer—typing fast, clicking fast, working late. The clones aren’t better. They’re just close enough.
What the Ecosystem Is Doing (or Not Doing)
The Open VSX team has pulled over 70 malicious extensions since the report went public. But the registry still lacks automated binary analysis tools capable of detecting obfuscated payloads. Unlike Microsoft’s marketplace, which uses a combination of static scanners, sandboxed execution, and human review, Open VSX relies on post-upload reporting. That delay is exploitable.
There are signs of movement. The Eclipse Foundation has acknowledged the gap and is exploring integration with third-party scanning tools like those from Snyk and SonarSource. But progress is slow. Open VSX doesn’t have Microsoft’s budget or dedicated security staff. It operates on community contributions and foundation funding—around $180,000 in allocated support over the past year, according to Eclipse’s public financials.
Meanwhile, VSCodium, one of the largest consumers of Open VSX, has updated its default extension gallery settings to warn users about unsigned or unverified publishers. Gitpod has introduced a curated allowlist for critical extensions in its workspace templates. But these are reactive steps. No major Open VSX consumer has implemented real-time behavioral monitoring for extension activity during runtime.
Compare that to GitHub’s recent moves in the npm ecosystem. Since 2022, GitHub has scanned over 4 million npm packages using CodeQL, flagging more than 50,000 with hidden malware. The infrastructure exists. It’s just not being applied to Open VSX at the same scale.
The Bigger Picture: Open Source Trust Is Running on Fumes
This attack isn’t just about one backdoor or one registry. It exposes a broader crisis in how open source tooling handles trust. Millions of developers rely on decentralized, open-publishing models because they reject vendor control. But in rejecting control, they’ve also rejected accountability.
Open VSX isn’t alone. The npm registry removed over 1,000 malicious packages in 2023 alone, many using the same typo-squatting tactics. The Python Package Index (PyPI) has seen a 300% increase in malicious package uploads since 2020, according to Sonatype’s annual threat report. Attackers aren’t shifting tactics—they’re iterating on a proven model.
The economics are clear. A single compromised developer machine in a tech company can yield access to source code repositories, internal APIs, and cloud infrastructure. That access can be sold on underground forums for $5,000 to $50,000, depending on the target. The cost of uploading 70 fake extensions? Nearly zero.
And the burden keeps falling on individual developers. They’re expected to audit publisher names, verify GitHub repositories, and disable auto-updates. But in real-world workflows, that doesn’t happen. A 2023 Snyk survey found that 68% of developers install extensions without checking the publisher. Why? Speed. Habit. Trust in the platform.
If open ecosystems want to survive, they need structural changes. Not just takedowns. Not just warnings. We need cryptographic signing of extensions, public transparency logs for publisher identities, and runtime monitoring baked into the IDE. Until then, open doesn’t mean free—it means exposed.
Why This Isn’t Just a VS Code Problem
This is a supply-chain attack with a distribution model that could replicate across any open plugin registry.
Think of Chrome Web Store. Think of npm. Think of WordPress plugins. Any ecosystem that prioritizes open publishing over gatekeeping is vulnerable to this exact tactic: mass cloning, subtle naming, delayed activation.
The difference? Most of those platforms have at least some automated detection. npm scans for obfuscated code. The Chrome Web Store flags hidden network calls. Open VSX has almost none of that. It’s a registry, not a security checkpoint.
What This Means For You
If you’re using VSCodium, Gitpod, or any IDE that pulls from Open VSX, you need to audit your extensions—now. Check every publisher name. Look for typos. Search for the official version on GitHub. If the extension doesn’t link to a public repo or the publisher isn’t verified, assume risk.
And reconsider blind auto-updates. These clones weren’t reported because they didn’t break anything. They worked perfectly—until they didn’t. Supply-chain security isn’t just about the code you write. It’s about the tools you trust to write it.
How long before the next clone wave hits a different registry? The tools are open. The methods are proven. And the targets are getting softer.
Sources: SecurityWeek, original report
