ForumsGeneralGlassWorm 2.0: The Danger of Transitive Dependencies in Open VSX

GlassWorm 2.0: The Danger of Transitive Dependencies in Open VSX

EDR_Engineer_Raj 3/14/2026 USER

The latest report on the GlassWorm campaign is a wake-up call. We're seeing a shift where threat actors are abusing extensionDependencies and extensionPack to turn seemingly benign extensions into trojan horses. Instead of embedding the malicious loader in the main extension manifest, they rely on the transitive nature of these dependencies to pull down the payload from a separate, seemingly unrelated listing.

This is a supply chain nightmare. The "parent" extension passes a basic static analysis review because it's clean until runtime resolves those dependencies.

To help everyone audit their local extension stores or downloaded .vsix files, I whipped up a quick Python script to flag packages with external dependencies before they hit your IDE.

import zipfile
import 
import sys

def audit_vsix(file_path):
    try:
        with zipfile.ZipFile(file_path, 'r') as zf:
            # VSIX structure usually has extension/package.
            try:
                manifest_data = zf.read('extension/package.')
            except KeyError:
                manifest_data = zf.read('package.')

            manifest = .loads(manifest_data)
            deps = manifest.get('extensionDependencies', [])
            packs = manifest.get('extensionPack', [])

            if deps or packs:
                print(f"[ALERT] {file_path} contains external references:")
                for d in deps: print(f"  - Dependency: {d}")
                for p in packs: print(f"  - Pack: {p}")
            else:
                print(f"[OK] {file_path} looks self-contained.")

    except Exception as e:
        print(f"[ERROR] Failed to parse {file_path}: {e}")

if __name__ == "__main__":
    for file in sys.argv[1:]:
        audit_vsix(file)

Anyone else blocking Open VSX registry entirely, or are you trying to set up an internal allow-list?

HO
HoneyPot_Hacker_Zara3/14/2026

Good share. We've started correlating network traffic from dev workstations to known Open VSX IPs against the EDR process tree. If the IDE spawns a shell that reaches out to the registry unexpectedly, we're squashing it. Here's the KQL query we're using in Sentinel to spot suspicious child processes of VS Code hosts:

DeviceProcessEvents
| where InitiatingProcessFileName in~ ("code.exe", "eclipse.exe", "theia.exe")
| where ProcessFileName in~ ("powershell.exe", "cmd.exe", "bash")
| where NetworkIPs contains "open-vsx.org"


It's noisy but caught a few devs trying to manually install unsigned themes.
MD
MDR_Analyst_Chris3/14/2026

We moved to an offline marketplace for this exact reason. Supply chain attacks on dev tools are the new phishing. The transitive dependency trick is nasty because most code review tools don't recursively analyze extensionDependencies by default. We implemented a pre-commit hook that rejects any repo containing a .vsix or .vscode configuration that references external extensions not on our internal allow-list. It's a bit draconian, but better safe than sorry.

Verified Access Required

To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.

Request Access

Thread Stats

Created3/14/2026
Last Active3/14/2026
Replies2
Views194