GlassWorm VS Code Extensions: How to Audit Your Dev Environment for Malicious Extensions

A fresh wave of GlassWorm extensions is seeding Open VSX — the open-source VS Code extension marketplace — with self-propagating malware. The extensions appear legitimate, mimic popular developer tools, and spread automatically once installed. If your team uses Open VSX or VS Code with an unmanaged extension policy, you need to audit now.

// 01 What GlassWorm Is and How It Propagates

GlassWorm is a campaign, not a single piece of malware. Attackers publish extensions to Open VSX that carry a worm component: once installed, the extension scans the victim’s machine for other VS Code-compatible environments (Cursor, VSCodium, Gitpod workspaces, remote SSH sessions) and attempts to install itself there too.

The propagation mechanism exploits the VS Code extension API’s ability to programmatically install other extensions. Specifically, the malicious extension calls:

vscode.commands.executeCommand(
  'workbench.extensions.installExtension',
  'attacker.malicious-extension-id'
)

This runs silently in the background without a user-visible prompt, because the installExtension command does not require an explicit user confirmation if invoked from within a trusted extension context.

What the payload does after propagation:

• Exfiltrates environment variables (harvesting API keys, tokens, .env files)
• Reads workspace files matching patterns: *.env, *.pem, config.*, credentials.*
• Establishes persistence via VS Code’s onStartupFinished activation event
• Connects to a C2 server over HTTPS using domain-fronting to avoid proxy inspection

// 02 How to Detect GlassWorm Extensions

Step 1 — List all installed extensions and their publishers

# VS Code CLI (works on Linux/macOS/Windows WSL)
code --list-extensions --show-versions

Pipe through to a file for review:

code --list-extensions --show-versions > ~/installed-extensions.txt
cat ~/installed-extensions.txt

Step 2 — Cross-reference against the known-bad publisher list

GlassWorm campaigns have used publisher IDs with slight misspellings of legitimate publishers. Check for:

# Example: look for typosquatted publisher names
grep -iE "(micros0ft|esllint|prettier-io|gitlens-ext|tabnin|copiloot)" ~/installed-extensions.txt

Also check for very new publishers with no web presence:
– Publisher with 0 other extensions on the marketplace
– Extension created within the last 30 days with >10k installs (install-count inflation is a known signal)
– No source repository linked in the marketplace listing

Step 3 — Inspect extension source directly

VS Code stores installed extensions on disk. Inspect the source:

# Linux/macOS
ls ~/.vscode/extensions/

# Each extension is a directory: publisher.extension-version/
# Look inside for obfuscated JavaScript
ls ~/.vscode/extensions/suspicious-publisher.extension-1.0.0/

# Search for the propagation command pattern
grep -r "installExtension" ~/.vscode/extensions/ 2>/dev/null
grep -r "executeCommand" ~/.vscode/extensions/ 2>/dev/null | grep -v ".map"

Flag any extension that calls installExtension programmatically — legitimate extensions almost never do this.

Step 4 — Check network activity from VS Code

On Linux with ss or netstat:

# See what VS Code extension host processes are connecting to
ss -tp | grep "Code Helper"

# On macOS
lsof -i -n -P | grep -i "code"

Flag unexpected outbound connections to non-Microsoft, non-known-CDN IPs from the VS Code extension host process (extensionHost).

Step 5 — Review activation events in package.json

# Check every extension's activation event
for dir in ~/.vscode/extensions/*/; do
  pkg="$dir/package.json"
  [ -f "$pkg" ] && echo "--- $(basename $dir)" && 
  python3 -c "import json,sys; d=json.load(open('$pkg')); print(d.get('activationEvents', []))"
done

Flag: "*" or "onStartupFinished" in extensions you did not deliberately install. These activate immediately on VS Code launch, before you interact with anything.

// 03 How to Remove a Suspect Extension

# Uninstall via CLI (replace with actual extension ID)
code --uninstall-extension publisher.extension-name

# Then manually delete the directory to ensure clean removal
rm -rf ~/.vscode/extensions/publisher.extension-name-*/

# Restart VS Code after removal

After removing, rotate any credentials that were accessible in the workspace during the infection window. Treat all tokens, API keys, and SSH keys stored in environment variables or config files as compromised.

// 04 Hardening Your Team’s Extension Policy

For individual developers

1. Only install from the official VS Code Marketplace (marketplace.visualstudio.com), not directly from Open VSX unless you’ve verified the publisher
2. Enable extension signature verification (available in VS Code 1.90+):
   json
// settings.json
{ "extensions.verifySignature": true }
3. Disable automatic extension updates in high-security environments:
   json
{ "extensions.autoUpdate": false }
4. Review the extension’s source repo before installing anything with filesystem or network access permissions

For teams and enterprises

Use an extension allowlist. VS Code supports a extensions.allowed policy via settings.json or group policy:

// .vscode/settings.json (commit to repo)
{
  "extensions.allowed": [
    "esbenp.prettier-vscode",
    "dbaeumer.vscode-eslint",
    "eamodio.gitlens"
  ]
}

Use a private extension registry. If your team uses Open VSX (e.g. in Gitpod, Eclipse Theia), host a private instance with an explicit allowlist rather than using the public Open VSX registry directly.

Audit via CI. Add an extension audit step to your onboarding or CI pipeline:

# Print any extension not in your approved list
APPROVED="esbenp.prettier-vscode dbaeumer.vscode-eslint eamodio.gitlens"
code --list-extensions | while read ext; do
  echo "$APPROVED" | grep -qw "$ext" || echo "UNAPPROVED EXTENSION: $ext"
done

// 05 Conclusion

GlassWorm is a reminder that the software supply chain runs all the way into your IDE. A malicious extension installed by one developer can propagate silently to every machine in your organisation. The audit steps above take under 10 minutes; running them across your team takes an afternoon. Do it before an attacker does it for you.

See also: For broader supply chain hardening including package managers and CI pipelines, see our guide on securing the software development lifecycle.