GlassWorm Supply-Chain Attack Abuses Open VSX Extensions
A new phase of the GlassWorm campaign abused 72 malicious Open VSX extensions and affected 151 GitHub repositories, targeting developers through software supply-chain channels. Researchers said the attackers escalated their tactics by abusing extensionPack and extensionDependencies, allowing seemingly harmless extensions to later pull in malicious ones after trust had already been established. The campaign also used invisible Unicode characters to hide malicious code, avoided Russian-language systems, and relied on Solana transactions as a dead-drop resolver for command-and-control infrastructure. It is a crafty reminder that developer tools can be attack surfaces too.
When your coding tools become the problem
Developers like efficiency. Attackers like that too, for entirely different reasons.
The latest GlassWorm campaign shows how software supply-chain attacks are becoming sneakier and more patient. Researchers found at least 72 malicious Open VSX extensions targeting developers, along with evidence that 151 GitHub repositories were hit as part of the broader activity. The targets included extensions masquerading as common coding utilities, formatters, linters and AI-assistant tools. In other words, the sorts of things developers install without much fanfare because they just want to get on with their day.
The trick: look harmless first, turn nasty later
What makes this campaign particularly clever is the way it abuses extension relationships. Rather than publishing every malicious extension with the bad payload built in from the start, the attackers used extensionPack and extensionDependencies so that an extension could appear benign initially, gain trust, and later begin pulling in a separate malicious component. That is rather like lending someone a perfectly normal toolbox and only adding the snake after they’ve taken it home.
The campaign also reused tactics seen elsewhere, including invisible Unicode characters to conceal malicious code and Solana transactions as a resilient method of retrieving command-and-control details. Researchers noted project-specific commit changes that looked realistic, suggesting the attackers may have used large language models to make their modifications blend in more naturally.
Why firms should care
This is not just a “developer problem”. If a compromised extension steals tokens, secrets or cloud credentials, the impact quickly spreads into source control, CI/CD systems and production environments. Any organisation with developers should be scrutinising extension use, package dependencies and repository activity much more carefully. Trusting tools simply because they look familiar is becoming an expensive habit.