GlassWorm Malware Returns via 73 OpenVSX Sleeper Extensions

Executive Summary

A resurgence of the GlassWorm malware campaign has been observed targeting the OpenVSX extension registry, deploying 73 sleeper extensions that initially appear benign but activate malicious behavior after an update. According to BleepingComputer, the campaign exploits trust in open-source Visual Studio Code extensions to infiltrate development environments, potentially enabling code execution, credential theft, and lateral movement. The sleeper tactic—where extensions pass initial review and only later download a malicious payload—poses a significant supply-chain risk to organizations relying on VS Code in CI/CD pipelines.

Technical Analysis

The GlassWorm campaign leverages OpenVSX, a community-maintained registry for VS Code extensions, to distribute extensions that contain no malicious code at the time of publication. After installation and a subsequent update, the extensions fetch a second-stage payload from a remote server, executing the GlassWorm malware. BleepingComputer reports that the 73 identified extensions mimic legitimate tools, such as theme packs, linters, and code formatters, to evade detection. The sleeper mechanism bypasses automated and manual review processes that scan only the initial submission. Once activated, GlassWorm can exfiltrate environment variables, SSH keys, and source code, and establish persistence via scheduled tasks or registry modifications. The campaign appears to target developers specifically, given the high-value access that compromised development environments provide to enterprise networks.

Mitigations & Recommendations

Organizations using VS Code should restrict extension sources to the Microsoft Marketplace or an internal curated registry, and disable automatic updates for third-party extensions. Defenders should audit installed extensions against the known malicious list published by OpenVSX administrators, and monitor for unusual outbound connections from VS Code processes. For CI/CD environments, consider containerizing builds to limit the blast radius of compromised extensions. No specific CVEs have been assigned to this campaign, as the attack relies on social engineering and supply-chain compromise rather than a software vulnerability.