GlassWorm Malware Attacks Return via 73 OpenVSX Sleeper Extensions

What happened

A new wave of the GlassWorm supply chain attack campaign has been identified by Socket researchers, deploying 73 extensions to the OpenVSX registry that are designed to appear benign on upload before turning malicious through a subsequent update or runtime payload fetch.

Six of the 73 extensions have been confirmed as activated and delivering malware. The remaining extensions are assessed with high confidence as dormant or suspicious based on consistent patterns with earlier GlassWorm waves. The shift to a sleeper model marks a strategic change from prior waves, which embedded malicious code directly in extensions and were caught quickly due to the scale and noise of those operations.

The 73 extensions are clones of legitimate OpenVSX listings, using the same icons, similar names, and comparable descriptions to avoid immediate detection. The primary differentiators are the publisher name and unique identifier. Rather than carrying malware directly, the extensions function as thin loaders that fetch payloads through one of three methods: retrieving a secondary VSIX package from GitHub at runtime via CLI commands, loading platform-specific compiled .node modules that fetch and execute additional payloads, or using heavily obfuscated JavaScript that decodes at runtime to download malicious extensions, sometimes including encrypted or fallback URLs.

Socket has not published technical details about the newest payload, but previous GlassWorm campaigns targeted cryptocurrency wallet data, credentials, access tokens, SSH keys, and developer environment data. GlassWorm has been active since October 2025 and has expanded across npm packages, GitHub repositories, the Visual Studio Code Marketplace, OpenVSX, and macOS environments via trojanized crypto wallet clients. A large-scale mid-March 2026 wave affected hundreds of repositories and dozens of extensions before being caught early by multiple research teams.

Who is affected

Developers who installed any of the 73 extensions identified by Socket are directly at risk. Given the loader design and the campaign’s history of targeting credentials, access tokens, and SSH keys, any development environment where the extensions were active should be treated as potentially compromised. Socket has published the full list of affected extensions.

Why CISOs should care

The sleeper model is a deliberate response to detection. GlassWorm’s earlier large-scale waves were noisy enough to attract multiple research teams simultaneously. The attacker’s answer was to reduce the initial footprint, upload clean extensions, and introduce the malicious payload later when scrutiny has passed. That makes the window between upload and detection harder to close, because the extension passes any scan performed at installation time.

The use of cloned legitimate listings also raises the bar for developer vigilance. Icon, name, and description match the real extension. Only the publisher name and identifier are different, details that most developers do not verify at install time.

3 practical actions

1. Cross-reference installed OpenVSX extensions against Socket’s published list of the 73 identified GlassWorm extensions: Any developer or organization that finds a match should treat the environment as compromised, rotate all secrets including API keys, access tokens, and SSH keys, and rebuild from a known clean state.
2. Enforce publisher verification as part of your extension approval process: The primary distinguishing characteristic between GlassWorm clones and legitimate extensions is the publisher identity. Establish a policy requiring verification of publisher name and unique extension identifier against the original listing before installation, particularly in CI/CD and shared development environments.
3. Monitor extensions for post-installation network activity and runtime payload fetching: The loader design means the malicious behavior occurs after installation, not during. Endpoint and network controls that flag extensions making unexpected outbound connections to GitHub or fetching secondary VSIX packages at runtime are a detection surface that installation-time scanning cannot cover.