72 Malicious Open VSX Extensions Linked to GlassWorm Campaign Now Using Transitive Dependencies

Since January 31, 2026, we identified at least 72 additional malicious Open VSX extensions, including transitive GlassWorm loader extensions targeting developers through extensionPack and extensionDependencies manifest abuse.

Mar 13, 2026

By Socket Threat Research Team (co-authored by Kirill Boychenko)

GlassWorm has not re-emerged so much as evolved, and our latest analysis shows a significant escalation in how it spreads through Open VSX. Instead of requiring every malicious listing to embed the loader directly, the threat actor is now abusing extensionPack and extensionDependencies to turn initially standalone-looking extensions into transitive delivery vehicles in later updates, allowing a benign-appearing package to begin pulling a separate GlassWorm-linked extension only after trust has already been established. We confirmed this pattern in otoboss.autoimport-extension, which references federicanc.dotenv-syntax-highlighting and oigotm.my-command-palette-extension, and identified additional live recursive cases such as twilkbilk.color-highlight-css, and crotoapp.vscode-xml-extension. This materially expands the campaign’s reach, lowers the visibility of the true malicious component, and makes one-time review of an extension’s original release insufficient for risk assessment.

Technically, the campaign retains the same core GlassWorm tradecraft while improving survivability and evasion. The newer variants still use staged JavaScript execution, Russian locale/timezone geofencing, Solana transaction memos as dead drops, and in-memory follow-on code execution, but they now rotate infrastructure and loader logic more aggressively: the campaign has shifted from Solana wallet BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC to 6YGcuyFRJKZtcaYCCFba9fScNUvPkGXodXE1mJiSzqDJ, continues to reuse 45[.]32[.]150[.]251 while adding 45[.]32[.]151[.]157 and 70[.]34[.]242[.]255, uses the Solana memo program MemoSq4gqABAXKb96qnH8TysNcWxMyWCqXgDLGmfcHr, replaces the earlier static AES-wrapped loader with heavier RC4/base64/string-array obfuscation, and moves decryption material out of the extension and into response headers such as ivbase64 and secretkey. Defenders should watch for late-version manifest changes that newly introduce extensionPack or extensionDependencies, staged extension.js code with Russian gating, Solana memo lookups, embedded crypto indicators such as AES key wDO6YyTm6DL0T0zJ0SXhUql5Mo0pdlSz and AES IV c4b9a3773e9dced6015a670855fd32b, and any extension that appears benign at first publication but becomes transitive in a later update. The primary attack surface is the Open VSX / VS Code extension install-and-update path, and the highest-risk assets are developer workstations and any local credentials, tokens, configuration data, or environment secrets reachable once the follow-on payload executes in memory.

The immediate priority is to audit extension histories, not just current code, for newly added extensionPack and extensionDependencies relationships, and to block or remove any GlassWorm-linked packages and infrastructure indicators from developer environments without waiting for additional registry takedowns.

GlassWorm’s Abuse of Extension Relationships

VS Code and compatible editors like Open VSX support these two manifest fields that allow one extension to pull in others automatically: extensionPack and extensionDependencies. Both are declared in the extension’s package.json and reference other extensions by their publisher.name identifier. When a user installs an extension that declares itself as an extension pack, the editor automatically installs every extension listed in the array alongside it.

The intended use case is convenience: As the VS Code documentation describes it, extension packs let developers bundle their favorite extensions together or create curated sets for a particular scenario; for example, a “PHP Development” that bundles together a debugger and a language service so that a new PHP developer can get started quickly.

  
{
  "extensionPack": ["xdebug.php-debug", "zobo.php-intellisense"]
}

Example of a legitimate PHP development pack highlighted in the official VSCode documentation on Extension Packs.

extensionDependencies works similarly but is meant for extensions that are required for the parent extension to work. In both cases, the editor installs them automatically alongside the main extension. Critically, neither mechanism requires the referenced extension to share a publisher, namespace, or any trust relationship with the parent. Any extension author can declare any other extension as a pack member or dependency.

GlassWorm is not limited to extensions that carry malicious code directly. It started to abuse these two VS Code-style manifest relationships (extensionPack and extensionDependencies) to turn one extension into an indirect installer for another. That gives the threat actor a useful transitive delivery path: an extension that appears benign on initial review can later be updated to add one of these fields and silently begin pulling a separate GlassWorm-linked package. For defenders, that means extension code alone is not enough. Manifest relationships, especially newly added extensionPack or extensionDependencies entries in later versions, must be treated as part of the attack surface because the malicious component may sit one layer beyond the extension the user knowingly installed.

Transitive GlassWorm Activity in Open VSX

We identified a new GlassWorm delivery technique in Open VSX that abuses extension manifest relationships to distribute malware transitively. Rather than embedding the GlassWorm loader in every malicious listing, the threat actor can publish an extension that appears benign and later cause the editor to install a separate GlassWorm-linked extension through extensionPack or extensionDependencies. This shifts the campaign model in an important way: some extensions now function as indirect delivery vehicles instead of direct malware carriers.

Among confirmed examples are otoboss.autoimport-extension@1.5.7, which contains an extensionPack reference to oigotm.my-command-palette-extension; otoboss.autoimport-extension@1.5.6, which contains an extensionPack reference to federicanc.dotenv-syntax-highlighting, an extension we identified and confirmed as GlassWorm-linked. In practice, this means a user can install an extension that appears non-malicious on its own, while still receiving GlassWorm through its declared extension relationship. This lowers the visibility of the malicious component, broadens the threat actor’s reach, and complicates both manual review and registry-side triage.

This behavior is not limited to a single package. Several of the extensions targeting end users displayed download counts inflated into the thousands, lending them a veneer of popularity with the goal of luring unsuspecting developers into installing them.

Screenshot of the malicious twilkbilk.color-highlight-css Open VSX extension, a GlassWorm-linked impersonator that mimics the legitimate color-highlight extension while using a namespace/publisher mismatch to appear trustworthy. The listing was still live at the time of writing and showed 3.5K reported downloads, which are likely inflated or otherwise manipulated by the threat actor to make the extension appear more established and credible.

As of March 13, Open VSX has removed the majority of the transitively malicious extensions, which is a positive operational sign. However, at the time of writing, we also identified live examples including twilkbilk/color-highlight-css and crotoapp/vscode-xml-extension, indicating that takedowns were ongoing but incomplete.

The extensions overwhelmingly impersonate widely installed developer utilities: linters and formatters like ESLint and Prettier, code runners, popular language tooling for Angular, Flutter, Python, and Vue, and common quality-of-life extensions like vscode-icons, WakaTime, and Better Comments. Notably, the campaign also targets AI developer tooling, with extensions targeting Claude Code, Codex, and Antigravity. In at least one case (daeumer-web.es-linter-for-vs-code), the publisher name is a direct typosquat of the legitimate ESLint publisher dbaeumer.

A key operational detail is that these packages do not begin as obviously transitive GlassWorm carriers. The threat actor first publishes an extension that appears standalone and does not initially declare a malicious dependency. In a later update, the threat actor adds an extensionPack or extensionDependencies reference to a separate GlassWorm loader. As a result, an extension that looked non-transitive and comparatively benign at initial publication can later become a transitive GlassWorm delivery vehicle without any change to its apparent purpose. For defenders, this materially raises the risk: reviewing the original release once is no longer sufficient, because the malicious dependency relationship may emerge only in a later update, at which point previously trusted installs can begin pulling GlassWorm indirectly through the normal extension update path.

GlassWorm Loader Evolution

Recent analysis shows that GlassWorm has continued to evolve since our January 31, 2026 report. Newer variants, including aadarkcode.one-dark-material@3.20.1, preserve the campaign’s core tradecraft while updating the components most vulnerable to exposure. The loader still uses staged JavaScript execution, Russian geofencing, Solana transaction memos as dead drops, and in-memory follow-on code execution, all of which remain strong continuity markers with the January 31, 2026 cluster. At the same time, the threat actor has rotated Solana infrastructure from BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC to 6YGcuyFRJKZtcaYCCFba9fScNUvPkGXodXE1mJiSzqDJ, introduced additional C2 IPs such as 70[.]34[.]242[.]255 and 45[.]32[.]151[.]157, expanded RPC redundancy, replaced the earlier static AES-wrapped loader with heavier RC4/base64/string-array obfuscation, and shifted decryption material from the extension itself to operator-controlled HTTP response headers. Despite these adaptations, overlapping infrastructure, including reuse of 45[.]32[.]150[.]251, and the continued use of the same underlying execution model strongly support attribution to GlassWorm.

Socket AI Scanner’s analysis of the malicious aadarkcode.one-dark-material Open VSX extension flags a staged GlassWorm-style loader in extension/out/extension.js, highlighting heavy obfuscation, runtime retrieval and decoding of follow-on code, execution via eval and vm.Script with full Node.js primitives exposed, and locale/time-based gating consistent with selective execution and anti-analysis behavior.

Outlook and Recommendations

GlassWorm is moving toward less visible, more resilient delivery: later-version manifest changes, transitive installation paths, heavier obfuscation, rotating Solana wallets and infrastructure, and threat actor-controlled decryption material. Defenders should expect more extensions that look benign at publication, then become malicious through updates that add extensionPack or extensionDependencies. That model is likely to spread because it hides the real malicious component behind normal extension-management behavior.

The priority now is to treat extension history, manifest diffs, and transitive relationships as first-class detection surfaces. Audit version-to-version changes for newly introduced extensionPack and extensionDependencies, review extension install/update chains rather than only current code, and hunt for GlassWorm indicators such as staged loaders, Russian locale/time gating, Solana memo lookups, and reused infrastructure. On endpoints, review developer workstations for exposed tokens, credentials, config files, and environment secrets reachable after in-memory follow-on execution.

Socket flags these exact relationships with a dedicated VS Code: Extension pack and VS Code: Extension dependency alert, which surface on package pages whenever an extension declares transitive install relationships. This gives users and security teams visibility into whether an extension ships other extensions before they install it.

The Socket GitHub App helps catch suspicious dependency additions and risky manifest changes before merge. The Socket CLI adds install-time visibility and policy enforcement for behaviors associated with GlassWorm-style loaders, including obfuscation, decrypt-and-execute logic, and unexpected network access. Socket Firewall blocks known malicious packages before fetch, including transitive dependencies, which matters when a package becomes malicious only after a later update. The Socket browser extension helps users spot suspicious packages while browsing, and Socket MCP reduces the chance that malicious or hallucinated packages enter projects through AI-assisted coding workflows.

Indicators of Compromise (IOCs)

Malicious Open VSX Extensions (Since Our January 31, 2026 Report)

Solana addresses

BjVeAjPrSKFiingBn4vZvghsGj9KCE8AJVtbc9S8o8SC
6YGcuyFRJKZtcaYCCFba9fScNUvPkGXodXE1mJiSzqDJ

Embedded Crypto Material

AES key: wDO6YyTm6DL0T0zJ0SXhUql5Mo0pdlSz
AES IVs (hex): c4b9a3773e9dced6015a670855fd32b

IP Addresses

45[.]32[.]150[.]251
45[.]32[.]151[.]157
70[.]34[.]242[.]255

MITRE ATT&CK

T1195.001 — Supply Chain Compromise: Compromise Software Dependencies and Development Tools
T1204 — User Execution
T1480 — Execution Guardrails
T1059.007 — Command and Scripting Interpreter: JavaScript
T1027.013 — Obfuscated Files or Information: Encrypted/Encoded File
T1102.001 — Web Service: Dead Drop Resolver

This post was originally published on the Socket blog.

Malware, Browser Extensions