GlassWorm campaign expands with 72 malicious Open VSX extensions that hide malware in dependency chains

A new wave of the GlassWorm supply chain campaign has pushed at least 72 more malicious Open VSX extensions into developer environments, according to Socket Research Team. The key shift is not just scale. Attackers are now hiding the malware behind transitive dependencies, which means an extension can look clean at first and only pull in the malicious component later through a normal-looking update.

That makes this version of the campaign more dangerous than a simple poisoned extension upload. Socket says the operators are abusing the legitimate extensionPack and extensionDependencies manifest fields to make trusted extensions install a hidden GlassWorm loader in the background after users already accepted the original package.

The broader risk is clear. IDE extensions often get deep access to source code, local files, developer secrets, tokens, and browser data. If a malicious extension reaches that environment quietly, the attacker can steal credentials, configuration data, and other sensitive material tied to software development workflows. Socket says that remains GlassWorm’s core objective.

What changed in the latest GlassWorm wave

Earlier GlassWorm activity focused on extensions that carried the malicious logic more directly. In this latest phase, Socket says the threat actors first publish extensions that appear benign and standalone. After those packages gain trust, the attackers push an update that modifies the manifest and adds a dependency link to a separate malicious loader. Because the loader arrives later and indirectly, initial code review of the first release may not catch the real payload.

Socket describes this as a significant escalation in how the campaign spreads through Open VSX. The report says the new packages imitate widely used developer utilities such as linters, formatters, and language tools, while also impersonating AI-focused coding assistants.

Why this technique works

This tactic exploits trust over time. A developer may install a harmless-looking extension, use it without issues, and stop thinking about it. Once the publisher appears safe, a later update can quietly introduce a dependency on a hidden malicious extension. Since the editor resolves those dependencies automatically, the second-stage payload can land without the same level of scrutiny. This is an inference based on Socket’s description of how extensionPack and extensionDependencies were abused.

That also means one-time reviews are no longer enough. Teams that only inspect an extension when it first appears may miss the real compromise if the dangerous change arrives in a later version. Socket’s write-up explicitly warns that standard initial code reviews become ineffective under this model.

What Socket says the attackers are impersonating

Source: Socket Research Team and follow-up reporting.

Technical changes in the malware

Socket says the latest GlassWorm variants also became harder to analyze and disrupt. The report describes a shift to heavier obfuscation, use of remote decryption material, and continued staged execution. It also says the campaign rotated Solana wallet infrastructure and added new command-and-control IP addresses, while keeping Russian locale and timezone checks that help the malware avoid some analysis environments.

Because Socket is the primary source here, the safest conclusion is that the campaign is evolving both in delivery and resilience, not merely growing in extension count. The delivery chain now blends social trust, registry mechanics, and staged payload behavior. That interpretation follows directly from Socket’s March 13 report.

What developers and security teams should do

• Audit installed extensions for any new extensionPack or extensionDependencies relationships added in later versions.
• Review full version history and update chains, not just the current visible code.
• Hunt for GlassWorm indicators such as staged loaders, Solana memo lookups, and locale-based execution filtering.
• Remove known malicious packages and rotate exposed environment tokens or secrets from affected developer machines.
• Treat IDE extensions as privileged software, because they can access source code, local secrets, and developer workflows.

Why this matters beyond Open VSX

GlassWorm shows how software supply chain attacks keep moving toward places developers trust by default. Package managers get most of the attention, but extensions are just as attractive because they sit close to code, terminals, secrets, and browsers. Previous research into GlassWorm already showed the campaign using Open VSX and VS Code-compatible ecosystems in stealthy ways, and this new phase pushes that strategy further.

The most important takeaway is simple: a clean install does not guarantee a clean update. In this campaign, the malicious step may arrive only after the extension has already earned the user’s trust. That is an inference based on Socket’s transitive dependency findings.

FAQ