# GlassWorm: 72+ Open VSX extensions weaponised via transitive loaders

> Socket linked at least 72 additional malicious Open VSX extensions to the GlassWorm campaign. Newer variants use `extensionPack` / `extensionDependencies` fields to transitively pull GlassWorm loaders rather than embedding malware directly. Obfuscation rotated to RC4 + base64 with keys delivered in HTTP response headers.

- Published: 2026-03-13
- Severity: high
- Kind: Compromise - A legitimate, already-used package, maintainer account, CI pipeline, or release tag was hijacked and a malicious version was published under a name people already depend on.
- Tags: worm, obfuscation, infostealer, crypto-wallet-drain
- Also known as: GlassWorm
- Detected by: Socket
- Incident ID: openvsx-2026-03-13-glassworm-transitive

## What happened

Socket researchers traced at least `72` additional malicious extensions on the Open VSX registry to the **GlassWorm** campaign first disclosed in late 2025. Rather than embedding malicious JavaScript directly, the newer wave abuses the `extensionPack` and `extensionDependencies` manifest fields so that a visually clean extension transitively installs a separate GlassWorm-loader extension under another publisher.

The loader payload retains GlassWorm hallmarks:

- **Solana memo-based dead-drops** - the implant queries Solana RPC endpoints (Tatum, GetBlock, BlockEden, `solana-rpc.publicnode.com` and others) for the current C2 host, encoded in transaction memos against attacker wallet `6YGcuyFRJKZtcaYCCFba9fScNUvPkGXodXE1mJiSzqDJ`.
- **RC4 + base64 string obfuscation**, with the RC4 key delivered in an HTTP response header rather than embedded in the JS, defeating static unpacking.
- **Editor-level code execution** on every reload, with credential, token, and crypto-wallet theft modules.

The transitive-loader pivot is significant because Open VSX takedowns and curl-based static scanners that focus on the visible extension never inspect the second-hop pack contents. Socket recommends auditing the full `extensions` tree, not just top-level installs, in every developer environment.

## Impact

- Developers installing seemingly-clean extensions also fetch GlassWorm loader extensions
- Solana memo-based dead-drops for resilient C2
- Editor-level code-execution on every editor reload

## What to do

1. Audit installed Open VSX extensions; remove any with `extensionPack` pulls to unknown publishers
2. Use editor extension allowlists in managed dev environments

## References

- [Open VSX Transitive GlassWorm Campaign](https://socket.dev/blog/open-vsx-transitive-glassworm-campaign) - Socket
- [GlassWorm Loader Hits Open VSX via Developer Account Compromise](https://socket.dev/blog/glassworm-loader-hits-open-vsx-via-suspected-developer-account-compromise) - Socket

---

Canonical page: https://dependencywatch.io/incident/openvsx-2026-03-13-glassworm-transitive
Markdown version: https://dependencywatch.io/incident/openvsx-2026-03-13-glassworm-transitive.md
Site index for agents: https://dependencywatch.io/llms.txt
DependencyWatch.io is operated by Precursor Security (https://precursorsecurity.com).