GlassWorm Malicious VS Code Extensions: Developer Credential Theft Defense Guide (2026)

GlassWorm Malicious VS Code Extensions: Developer Credential Theft Defense Guide (2026)

By Fanny Engriana Β· Β· 10 min read Β· 4 views
Disclaimer: This article is for educational and defensive cybersecurity purposes only. The information here is based on public threat intelligence disclosures from Socket, Truesec, BleepingComputer, Snyk, and TheHackerNews as of May 2026. Threat actor capabilities evolve quickly β€” always verify current advisories before acting on any specific defensive control. Suspected compromise on systems handling regulated data (PCI, HIPAA, SOC 2) requires formal incident response. Consult qualified professionals for production environments.

In April 2026, security researchers at Socket and Aikido confirmed the third resurgence of GlassWorm β€” a self-propagating worm hiding inside Visual Studio Code extensions on the OpenVSX marketplace. Seventy-three new malicious extensions surfaced between March 15 and April 27, 2026, with combined telemetry suggesting more than 50,000 installs before takedown.

For developers, this matters more than the average malware story. VS Code has become the daily driver for most of us. I have used it (and its predecessors going back to Sublime Text and Atom) for the entire 11+ years I have been shipping client work at Warung Digital Teknologi. Across our 50+ projects spanning Laravel, Vue, Flutter, and React Native, my VS Code instance holds GitHub tokens, AWS access keys, database connection strings for production systems, and OAuth refresh tokens β€” exactly what GlassWorm is built to steal.

This guide walks through what GlassWorm actually does, how to check whether you are already compromised, and the eight defensive controls I personally rolled out across our internal dev environments after the third wave broke.

What Is GlassWorm and Why It Is Different

GlassWorm is not just another typosquat malware. The campaign first surfaced in October 2025 and had two characteristics that made it dangerous from day one.

1. Invisible Unicode injection. The malware hides its loader inside extension code using zero-width Unicode characters such as U+200B, U+200C, U+200D, U+2060, and U+FEFF. When a developer opens the source on the OpenVSX marketplace page, the malicious payload appears as blank space. Even trained reviewers can miss it on a first pass because most syntax-highlighting tools render those characters identically to whitespace.

2. Self-propagation through stolen npm tokens. Once GlassWorm captures a developer's npm publish credentials, it republishes itself into other packages that the developer maintains. The worm spreads laterally through the open-source ecosystem with no human intervention required.

The April 2026 wave added a new trick: transitive dependency abuse. According to Socket's research team, instead of embedding the malicious loader directly into each extension, the attackers used the extensionPack and extensionDependencies manifest fields. A clean-looking extension pulls in a "helper" extension on install, and that helper carries the payload. This bypasses scanners that only check the primary package manifest.

In my experience auditing extension behavior across our internal team, this dependency chain pattern is exactly what we missed during code reviews. We read the main extension.js, not what gets pulled in transitively. After this wave, we changed our review checklist.

What GlassWorm Steals: The Honest Inventory

Reports from Truesec and BleepingComputer give a precise inventory of what the worm exfiltrates once it executes:

  • GitHub access tokens β€” pulled from ~/.config/gh/, ~/.gitconfig, and VS Code's secret storage
  • npm publish tokens β€” read from ~/.npmrc and CI environment variables, then validated against the npm registry API to confirm publish rights
  • Git credentials and SSH private keys β€” including everything in ~/.ssh/
  • 49 cryptocurrency wallet browser extensions β€” MetaMask, Phantom, Coinbase Wallet, Trust Wallet, and others
  • Cloud provider API keys β€” AWS, GCP, Azure stored in standard SDK config locations
  • A SOCKS proxy server β€” installed silently to turn the developer machine into criminal infrastructure for further attacks
  • A hidden VNC server β€” providing full remote desktop access to attackers

The hidden VNC component is the part that should make every solo developer reading this nervous. Once attackers have remote desktop, every other defense β€” password manager, 2FA app, hardware key β€” runs on a machine that no longer belongs to you. The attacker watches you authenticate and simply waits.

Developer at laptop investigating malware compromise

How to Check If Your Machine Is Infected

This is the section I would want first if I were a reader. Run these checks in order. I tested all of them on my own MacBook running VS Code 1.95 before publishing this guide.

1. List your installed extensions

Open a terminal and run:

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

Open that file. The Snyk team and independent researchers have published working lists of confirmed-malicious GlassWorm extensions. The community-maintained GitHub repository unic/glassworm-detect hosts an updated bash script that diffs your installed list against the indicator-of-compromise (IOC) list automatically.

2. Check for invisible Unicode in extension files

Extensions live under ~/.vscode/extensions/ on macOS and Linux, and %USERPROFILE%\.vscode\extensions\ on Windows. The following one-liner flags any JavaScript file containing zero-width characters:

grep -rPl '[\x{200B}\x{200C}\x{200D}\x{2060}\x{FEFF}]' ~/.vscode/extensions/ 2>/dev/null

When I ran this on my own machine, two false positives came up β€” both were minified bundles from legitimate extensions that happened to contain zero-width joiners. The point of the check is to investigate, not to panic on the first match. Open each flagged file and look for executable code constructed from those invisible characters.

3. Look for suspicious outbound connections

GlassWorm's command-and-control beacons hit specific endpoints. Run this to see active sockets owned by VS Code processes:

lsof -i -P | grep -i 'code\|electron'

Anything connecting to suspicious IPs in countries you do not operate in is worth investigating. In my dev environment, VS Code only legitimately reaches out to update.code.visualstudio.com, marketplace.visualstudio.com, GitHub, and any extension-specific API the developer is actively testing. A connection to an unfamiliar IP on port 443 is not automatic compromise, but unfamiliar IPs on non-HTTP ports such as 1080 or 9050 are red flags.

4. Audit your npmrc and credential stores

If your _authToken line in ~/.npmrc is something you cannot account for, or if there is an entry pointing to a non-standard registry URL such as a typosquat of registry.npmjs.org, treat it as compromise. Likewise, scan your ~/.aws/credentials file for unexpected profiles.

If You Find Anything: The First-Hour Response

Do not wait. The longer GlassWorm sits, the more lateral movement happens, and the larger your blast radius becomes. Here is the order of operations I rehearsed with my team after the campaign was disclosed:

  1. Disconnect the machine from the network. Pull WiFi, unplug Ethernet. Do not shut down β€” volatile memory may help forensics later if you decide to engage an incident response firm.
  2. From a separate clean machine, rotate every token. GitHub Personal Access Tokens, npm tokens, AWS keys, GCP service account keys, OAuth refresh tokens for any IDE-connected service. Every one of them. Yes, even the read-only ones β€” attackers chain read-only access into reconnaissance.
  3. Revoke OAuth grants. Visit github.com/settings/applications and revoke anything you do not immediately recognize.
  4. Check audit logs. GitHub audit log for any push activity, PR creation, or workflow run you did not initiate in the last 30 days. npm session log at npmjs.com/settings/[username]/tokens for unknown sessions.
  5. Wipe and reinstall VS Code. Uninstalling extensions is not enough. Delete the entire ~/.vscode/ directory plus VS Code's user data folder (~/Library/Application Support/Code/ on macOS, %APPDATA%\Code\ on Windows).
  6. Reformat the development machine. Full OS reinstall is the only honest answer if you found confirmed compromise. The VNC and SOCKS server components persist outside of VS Code itself and are designed to survive uninstalls.

This sequence is painful. I know. When Checkmarx publicly confirmed data theft from a related supply chain incident in April 2026, even their engineering team had to go through this exact sequence at the cost of multiple working days.

Eight Defensive Controls I Implemented

Here is what changed in our dev environment after the April 2026 wave. None of these are theoretical β€” every item is something I rolled out across my own machine and recommended to the two contractors we work with.

1. Pin every extension to an exact version

VS Code defaults to auto-updating extensions in the background. That is exactly how GlassWorm spreads β€” an extension you installed clean gets a malicious update pushed silently. Disable auto-update in your settings.json:

{
  "extensions.autoUpdate": false,
  "extensions.autoCheckUpdates": false
}

Then commit a .vscode/extensions.json file per project listing exactly the extensions and versions that project requires. This makes the developer toolchain reproducible and reviewable, not background-updated.

2. Prefer the official Microsoft Marketplace over OpenVSX

The April 2026 GlassWorm wave concentrated on OpenVSX. The Microsoft Marketplace runs more aggressive review (still imperfect, but better). If you use VS Code forks like Cursor, VSCodium, or Windsurf β€” which default to OpenVSX β€” be aware of this tradeoff. TheHackerNews reported in January 2026 that some forks even suggest installing missing extensions from OpenVSX, which increases exposure rather than reducing it.

3. Run developer work in containers when possible

Devcontainers (.devcontainer/devcontainer.json) put your project's tooling inside a Docker container. If a malicious extension fires inside the container, it does not have direct access to your host's ~/.ssh/, ~/.npmrc, or AWS credentials unless you explicitly mount them. I converted three of our seven aggregator-site repos to devcontainers in May 2026, and the friction was lower than I expected β€” about 90 minutes per repo for the first conversion, then under 20 minutes each for the next two.

4. Move npm tokens to short-lived OIDC

For CI publishes, GitHub Actions now supports OIDC-based npm publishing β€” no long-lived token stored anywhere. For local dev, scope tokens narrowly: read-only when you are not actively publishing, and automation-only tokens that cannot bypass 2FA. The npm CLI 10+ supports finer-grained tokens than older versions; verify yours with npm --version.

5. Store credentials in OS keychain, not dotfiles

~/.npmrc and ~/.gitconfig are plaintext files readable by any process running as your user. macOS Keychain, Windows Credential Manager, and gnome-keyring on Linux are encrypted at rest and require user authorization to read. The Git Credential Manager (cross-platform) handles this for git authentication. For npm, the npm login --auth-type=web flow on npm 9+ stores tokens in the OS keychain instead of .npmrc.

6. Block VNC and SOCKS ports at the OS firewall

Outbound default-deny is the gold standard, but realistic for most solo devs is at least blocking inbound on the VNC default ports (5900-5910) and known SOCKS proxy ports (1080, 9050). On macOS, Little Snitch (paid) or LuLu (free, from Objective-See) catches new outbound connections on first run and asks for explicit allow. I have run LuLu for two years across my main work machine without issues.

7. Run an extension audit weekly

A 5-minute Sunday ritual: run code --list-extensions --show-versions, then diff against last week's snapshot. New versions installed unexpectedly? Investigate immediately. I keep a ~/.devops/extension-snapshots/ folder with timestamped exports going back six months.

8. Subscribe to Socket and Snyk advisories

Both publish IOC feeds for npm and OpenVSX malware. Snyk's GlassWorm guidance updates as new variants drop. For solo devs, these advisories are free and high-signal β€” much higher signal than scrolling Twitter for security news.

Organizational Defenses for Teams Beyond One Developer

If you manage a team, three controls above all the rest:

  • Internal extension allowlist. Block all OpenVSX and Marketplace traffic at the corporate firewall, mirror approved extensions to an internal Artifactory or Nexus repository, and pin developers to the mirror. This is what large enterprises like financial institutions have been doing for years.
  • EDR with VS Code-specific rules. CrowdStrike, SentinelOne, and Microsoft Defender for Endpoint can flag VS Code extension processes spawning unusual child processes (PowerShell, curl, network listeners). Tune detection rules for your environment.
  • Quarterly secret rotation. Even without a known breach, rotating all developer secrets every 90 days limits the value of any silent compromise that slipped past detection.

Frequently Asked Questions

Is the official Microsoft VS Code Marketplace safe from GlassWorm?

It is safer than OpenVSX as of May 2026, but not immune. Microsoft removed several GlassWorm-affiliated extensions from its marketplace in March 2026 after researcher disclosure. Treat marketplace verification as a strong-but-not-perfect signal, never as a guarantee.

Are JetBrains IDEs (IntelliJ, WebStorm, PyCharm) affected?

No public reports tie GlassWorm to JetBrains plugin marketplaces specifically as of this writing. JetBrains plugins go through tighter review than OpenVSX, but the same supply chain risk pattern applies. Pin your plugin versions and audit installations regularly regardless of editor.

Does using Cursor or VSCodium make me more vulnerable?

Both default to OpenVSX, where the GlassWorm campaign concentrated. They are not malicious themselves, but the default extension source has been more targeted. You can switch them to use the Microsoft Marketplace via configuration, though that may breach Microsoft's terms of service for some derivatives β€” verify the licensing situation before doing so.

I installed a flagged extension months ago and uninstalled it. Am I clean?

Probably not. If the extension fired its payload during the install, the SOCKS proxy and VNC components persist outside VS Code. Run the network audit step (lsof -i -P) and consider a full machine review at minimum. Better still, treat that machine as compromised until proven otherwise.

What about my crypto wallet?

If you had any of the 49 targeted browser wallet extensions installed on the same machine where a GlassWorm extension ran, treat the wallet as compromised. Move funds to a hardware wallet from a known-clean machine immediately. Hardware wallets such as Ledger and Trezor sign transactions on the device itself, so even a fully compromised host machine cannot drain them without physical access.

How do I know whether my company is using OpenVSX?

Check your VS Code settings for the extensions.gallery URL. If it points to open-vsx.org or any non-Microsoft domain, you are on a third-party gallery. Ask your IT or security team about their extension provisioning policy.

Bottom Line

GlassWorm matters because it broke a developer assumption I held for 11+ years: that the IDE itself was a trusted execution environment. It is not. Extensions are arbitrary code running with the same privileges as your editor β€” and increasingly, your editor has access to everything that matters professionally, from production database credentials to crypto wallet keys.

The eight defenses above are not security theater. They are the practical baseline I now run across every machine in our shop after watching this campaign unfold across three waves in seven months. If you are a solo developer, do at least the first four. If you manage a team, do all eight plus the organizational layer.

The next supply chain worm is being written right now somewhere. Treat your dev environment like the production system it has effectively become.


Final Disclaimer: This article reflects publicly disclosed information as of May 2026. Threat actor capabilities evolve. Always cross-reference with current advisories from CISA, NIST, the Microsoft Security Response Center, and your IDE vendor before relying on any specific defensive control. This article does not constitute legal, regulatory, or compliance advice. If you suspect compromise on systems handling regulated data such as PCI cardholder data, HIPAA-protected health information, or SOC 2 audit-scope systems, engage qualified incident response professionals immediately.

About the author: Fanny Engriana has been shipping production software for 11+ years across 50+ client projects at Warung Digital Teknologi, including ERP, hotel management, POS, and AI-powered platforms. Verify on LinkedIn.

Authoritative sources cited: Socket Research Team, Truesec Hub, BleepingComputer, Snyk, TheHackerNews.

Found this helpful?

Subscribe to our newsletter for more in-depth reviews and comparisons delivered to your inbox.

Related Articles