GlassWorm attacks OpenVSX: 73 sleeping extensions that hide malware and steal your secrets

A new wave of the campaign known as GlassWorm has rehit the ecosystem of editor extensions by appearing 73 "sleeping" packages in OpenVSX, of which six have already been activated and deliver malicious load, according to the research published by Socket. The technique used is of concern for its simplicity and effectiveness: the extensions are initially uploaded as harmless devices and, after a later update, change their behavior to download and install additional code or to load compiled modules (.node) that contain malicious logic.

What makes this campaign particularly insidious is the visual supplanting tactic of legitimate listings: icons, names and very similar descriptions that deceive the developer who trusts the appearance rather than verify the unique editor or identifier. In many cases, the first package acts as a light "loader" that, in running time, downloads VSIX packages from repositories in GitHub, runs CLI commands to install them, or runs heavily obfuscated JavaScript code that disfigures backup URLs and payloads.

The potential impact is not just the remote execution of code on a developer's machine: it is a gateway to sensitive secrets. previous GlassWorm campaigns have looked for cryptomoneda portfolio keys, credentials, access tokens, SSH keys and development environment data. If a single committed workstation can exfilter CI / CD or tokens credentials that give access to repositories and cloud services, the scope can quickly scale to infrastructure commitments and supply chains.

If you think you have installed any of the extensions involved, the first thing is to take on a possible exposure and act quickly: Uninstall suspicious extensions, checks unusual network processes and connections, isolates the affected machine and, above all, rotates all the credentials and tokens that could have been accessible from that computer (repository tokens, SSH keys, cloud service credentials, API keys and wallet keys). Socket has published the complete list of identified extensions and is the starting point for identifying affected facilities: Socket - 73 Open VSX sleeper extensions.

Beyond the immediate response, there are practical measures to mitigate this type of risk in the future: apply egress controls (output filtering) to block automatic downloads from unreliable URLs, avoid installing extensions from unverified repositories in production environments or CI, and use isolated environments (virtual machines or ephemeral containers) to test new extensions before incorporating them into the workflow. It is also advisable for organizations to implement secret management and automatic rotation policies, and to monitor the subscription and permissions of the accounts that publish extensions.

For operators and ecosystem maintainers such as OpenVSX and extension marketplaces, the case again highlights the need for more stringent mechanisms for publicators' verification and clone detection: signed packages, validation of the publisher ID and visual similarity detection should be minimum requirements, together with automated analysis that detects "sleeping" behaviors or discharge patterns in running time. You can check the OpenVSX platform for details and policies of the repository: OpenVSX.

From a compliance and risk perspective, campaigns such as GlassWorm require security teams to integrate the software supply chain review into the deployment processes: unit audits, device scanning and SBOMs (list of components) to detect unauthorized changes and reduce the exposure window. For general guidance on risk management in supply chains, CISA offers useful material that can help prioritize controls: CISA - Supply Chain Risk Management.

If you detect evidence of engagement, document and preserve logs and artifacts before cleaning the equipment, notify your security team and marketers (OpenVSX and, if appropriate, Socket equipment or equivalent platforms), and prepare for safe reconstruction of the environment (clean reinstallation and restoration from verified backups). Rapid containment and the rotation of secrets are the actions that most reduce damage in the short term.

GlassWorm is an example of how attackers are refining supply tactics: instead of directly introducing malware, they prefer to enter through the front door with benign artifacts and activate the malicious load later. For developers and security officials this requires a shift from a default confidence mentality to a continuous verification- check the publisher ID, monitor extension updates, limit permissions and automate the rotation of secrets are concrete steps that reduce the risk of becoming a victim of this or other similar campaigns.