The Sleeper Strategy: GlassWorm's Evolution Into Delayed-Activation Supply Chain Attacks- 181

June 12, 2026

The extension passed every security check when it was uploaded. It was clean — because at the time of upload, it was. The malicious payload arrived later, in an update, after the extension had been installed by developers who had no reason to look again at something they had already trusted. GlassWorm's latest wave has refined this sleeper strategy into a systematic method: 73 extensions submitted to the OpenVSX ecosystem, benign on arrival, waiting for the moment the operators choose to activate them.

GlassWorm, first documented in October 2025, has been a persistent supply chain threat across developer tooling ecosystems — npm packages, GitHub repositories, the Visual Studio Code Marketplace, and OpenVSX. Its latest wave, documented by application security company Socket, shows a significant tactical evolution in how the campaign attempts to avoid detection: rather than embedding malicious code in extensions at upload time, the 73 extensions identified in this wave were uploaded as benign packages that become malicious only after a subsequent update.

The sleeper strategy addresses a specific defensive weakness. Registry security monitoring increasingly focuses on new package submissions, running automated analysis on newly uploaded code to detect malicious indicators before packages are distributed widely. An extension that passes that analysis clean — because it is clean at upload time — may not face the same level of scrutiny when updates are pushed. Of the 73 extensions Socket identified as part of the GlassWorm wave, six have been activated and are delivering malware. The remaining 67 are assessed as dormant or suspicious, waiting for the moment the operators choose to push the malicious update.

The delivery mechanisms in the activated extensions are varied. Some retrieve a secondary VSIX package from GitHub at runtime and install it using CLI commands — the malicious payload never resides in the extension itself but is pulled from external infrastructure when execution begins. Others load platform-specific compiled modules containing the core malicious logic, including payload fetching and cross-platform installation routines. A third variant relies on heavily obfuscated JavaScript that decodes at runtime to fetch and install malicious extensions, sometimes including encrypted fallback URLs for payload retrieval if primary infrastructure is unavailable.

The extensions are clones of legitimate listings — same icons, similar naming, similar descriptions — with differences in publisher name and unique identifiers that require active attention to notice. The attack is not technically sophisticated. It is designed for developers who install extensions without examining publisher provenance carefully, which is most developers most of the time. The credential theft target profile remains consistent with earlier GlassWorm waves: cryptocurrency wallet data, developer credentials, access tokens, SSH keys, and developer environment secrets. Developers who installed any of the 73 identified extensions are advised to rotate all secrets and conduct a full environment audit regardless of whether their specific installation has been confirmed active.