GlassWorm Shifts to Transitive Open VSX Dependencies in Developer Supply-Chain Push

GlassWorm is no longer just a story about obviously malicious extensions. The latest research shows the campaign is evolving into a broader software supply-chain problem by abusing how Open VSX extensions can automatically pull other extensions during installation. That shift matters because it lets an actor hide the truly malicious component one layer deeper inside the dependency chain, reducing the odds that a developer or a marketplace reviewer will spot the risk in time.

According to Socket, the campaign has been linked to at least 72 additional malicious Open VSX extensions since late January 2026. More importantly, some of those packages now abuse extensionPack and extensionDependencies relationships to act as indirect delivery vehicles. Microsoft’s own Visual Studio Code documentation confirms these manifest fields can automatically install referenced extensions, which makes them convenient for legitimate packaging but also useful to attackers when trust in one extension is used to smuggle in another.

The result is a more dangerous pattern for threat intelligence: a package can appear benign at first, gain credibility, and later be updated to silently install a second GlassWorm-linked extension. For defenders, that changes the problem from “scan suspicious code” to “monitor evolving extension relationships and update paths across the developer toolchain.”

Why the new GlassWorm technique matters

The key change in this campaign is transitive delivery. Instead of embedding the loader in every malicious extension, the operator can make one extension reference another through manifest metadata. If the user installs the first package, the editor may automatically fetch the second. That means the visible extension a developer trusts may not be the same package that ultimately delivers the payload.

Socket said the campaign still uses familiar GlassWorm tradecraft, including staged JavaScript execution, Russian locale checks, Solana memo lookups, and heavier obfuscation. The newer twist is operational: the attacker can now delay or relocate the malicious behavior so it sits in a linked extension rather than the one that first attracted the install.

That lowers visibility in several ways:

• It weakens one-time extension review.
• It creates room for a benign-looking package to become malicious in a later update.
• It complicates incident scoping because defenders may initially inspect the wrong extension.
• It widens blast radius across developer endpoints where tokens, cloud credentials, and local secrets are often within reach.

This is not only an Open VSX problem

Aikido reported that the same GlassWorm actor is also tied to a March 2026 wave of hidden-Unicode injections across at least 151 GitHub repositories, with related activity observed in npm and VS Code ecosystem packages. That matters because it suggests coordination across multiple developer trust layers rather than a single opportunistic campaign.

In practice, this means the same adversary pattern is showing up in:

• extension marketplaces,
• GitHub repositories,
• npm packages, and
• AI-focused developer tooling.

That multi-ecosystem spread is what turns GlassWorm into a strategic supply-chain issue rather than a narrow marketplace clean-up problem. If developers inherit risk from repositories, packages, and extensions at the same time, traditional “download only trusted tools” guidance becomes much less reliable.

What defenders should check now

Security teams should treat developer workstations as production-relevant assets, not just engineering endpoints. A successful compromise in this layer can expose source code, build secrets, API tokens, signing material, and internal environment data. In many environments, that is enough to create follow-on access without directly exploiting customer-facing infrastructure.

Three actions deserve immediate attention:

1. Audit extension history, not just current code

Review recently installed or updated Open VSX and VS Code-compatible extensions for newly introduced extensionPack or extensionDependencies fields. The risk is often in the relationship graph, not the obvious package contents.

2. Hunt for post-install behavior on developer endpoints

Look for suspicious outbound connections, script execution chains, secret access patterns, and any signs of command-and-control resolution tied to extension activity. If an extension installs quietly and then reaches out for second-stage logic, the endpoint telemetry is often where the real story appears.

3. Tighten controls around local secrets

Developer machines often carry cached tokens, cloud credentials, package registry access, and CI/CD material. Reducing standing access, segmenting high-value credentials, and using short-lived tokens can sharply reduce the impact of malware on engineering endpoints.

Strategic takeaway

GlassWorm’s newer Open VSX behavior is important because it attacks trust inheritance. The campaign does not need every package to look overtly malicious if it can turn a tolerated extension into a delivery path for a linked one. Combined with parallel GitHub and npm activity, this shows how modern software supply-chain operations increasingly target the places where developers discover, install, and update tools every day.

For defenders, the lesson is straightforward: extension manifests, dependency relationships, and update history now deserve the same scrutiny as source code itself. If your security program still treats developer tooling as low-risk convenience software, GlassWorm is a sharp reminder that the build environment is part of the attack surface.

Sources

• Socket, "72 Malicious Open VSX Extensions Linked to GlassWorm Campaign Now Using Transitive Dependencies," published March 13, 2026.
• Aikido, "Glassworm Is Back: A New Wave of Invisible Unicode Attacks Hits Hundreds of Repositories," published March 2026.
• Microsoft Visual Studio Code, "Extension Manifest" reference for extensionPack and extensionDependencies.
• The Hacker News, "GlassWorm Supply-Chain Attack Abuses 72 Open VSX Extensions to Target Developers," published March 2026.

References

1. Socket — 72 Malicious Open VSX Extensions Linked to GlassWorm Campaign Now Using Transitive Dependencies
2. Aikido — Glassworm Is Back: A New Wave of Invisible Unicode Attacks Hits Hundreds of Repositories
3. Visual Studio Code — Extension Manifest reference
4. The Hacker News — GlassWorm Supply-Chain Attack Abuses 72 Open VSX Extensions to Target Developers