A sophisticated supply-chain attack campaign has recently been uncovered in the open-source ecosystem, leveraging trusted Visual Studio Code (VS Code) extensions to deploy the GlassWorm malware loader. The incident, disclosed on January 31, 2026, by security researchers at Socket’s Threat Research team, marks a concerning escalation in how attackers are leveraging legitimate developer tools and compromised publisher credentials to silently infect developer environments.

What Happened: A Trusted Marketplace Abused

The Open VSX Registry, an alternative extension repository often used by developers working with VS Code and community-driven editors, was abused to publish malicious updates to legitimate extensions. On January 30, threat actors managed to publish tainted versions of four previously clean extensions under the existing oorzc author namespace. These utilities had been available for years and collectively accumulated more than 22,000 downloads before the malicious versions were removed.

According to the reporting, this attack did not rely on cloning or typosquatting—common tactics seen in earlier malware waves—but instead appears to have abused stolen or leaked developer publishing credentials. The Open VSX security team assessed the activity as consistent with a leaked token or unauthorized access to the publisher’s account.

The compromised extensions included:

• FTP/SFTP/SSH Sync Tool (oorzc.ssh-tools — v0.5.1)
• I18n Tools (oorzc.i18n-tools-plus — v1.6.8)
• vscode mindmap (oorzc.mind-map — v1.0.61)
• scss to css (oorzc.scss-to-css-compile — v1.3.4)

How GlassWorm Works: Loader, Evasion, and Post-Infection Behavior

Once installed, the malicious VSIX packages do not execute obvious malicious routines immediately. Instead, they contain a staged loader design that performs several stealthy actions:

• Dynamic Execution: At runtime, the loader decrypts and evaluates embedded JavaScript code. This approach avoids static payload signatures and makes detection using traditional scanning methods more difficult.
• Russian-Locale Avoidance: The malware checks the host environment for Russian language settings or time zones and avoids execution on systems that match these criteria—a tactic common among many criminal groups seeking to evade local law enforcement or reduce collateral spread.
• Blockchain-Based Command and Control: Rather than hard-coding a single command server, the loader fetches follow-on payload configuration from memos written into transactions on the Solana blockchain. This design allows the attacker to rotate infrastructure and evade takedown without republishing the extension itself.

After obtaining the next-stage payload, the malware can execute additional code with broader impact. In samples analyzed by Socket, this includes macOS-focused information theft—harvesting browser credentials, cookie databases, keychain material, and cryptocurrency wallet data from popular wallet apps like MetaMask, Exodus, and Electrum.

Critically, the loader also targets sensitive developer credentials and configuration files, such as AWS credentials and SSH keys. These artifacts can grant attackers access to cloud environments or code repositories long after the initial compromise.

A Broader Pattern: GlassWorm’s Continuing Evolution

This January 2026 incident is not an isolated spike but part of a broader GlassWorm campaign that has been active since at least October 2025. Earlier waves included malicious packages that used invisible Unicode characters and other evasion techniques to bypass human and automated review systems. These versions infected tens of thousands of developers before being removed and sometimes resurfaced in waves spanning other marketplaces, including the official VS Code Marketplace.

Security researchers have described GlassWorm as one of the first self-propagating malware families targeting VS Code extension supply chains, and the campaign has evolved to mix credential theft, advanced loaders, blockchain C2, and repeated exploitation of trusted developer resources.

Industry Response and Mitigation

After the malicious versions were identified, the Open VSX security team deactivated the affected publisher’s tokens and removed the poisoned releases from the registry. Because multiple versions of the affected extensions were tainted, some were entirely blacklisted to prevent future installs.

Developers and organizations are strongly encouraged to:

• Review and audit all installed VS Code extensions, especially those from less familiar publishers.
• Revoke and rotate any credentials that may be stored locally, including npm tokens, SSH keys, and cloud service keys.
• Monitor for unauthorized changes to development environments or unexpected network connections performed by extension processes.

This incident underscores the emerging reality that open-source supply-chain security is now a front-line defensive concern, not just for library dependencies but for the tools developers use day-to-day.