GlassWorm returns: 73 'sleeper' extensions on OpenVSX, malicious only after install
Extensions that pass scanning at install and turn malicious after an update. The model where you scan the artefact once and stop watching is finally broken.
Seventy-three malicious extensions in a fresh wave of the GlassWorm campaign on OpenVSX, the open-source VS Code marketplace. The new wrinkle is the term BleepingComputer reports the campaign as using: “sleeper”. The extensions install cleanly, pass any artefact scan that runs at install, and only turn malicious after a later update from the same publisher.
This is the third or fourth round of this pattern in eighteen months — different campaigns, similar mechanics — and it’s worth stating plainly. The scan-on-install model is broken for developer-tool ecosystems. It assumes the artefact you scanned is the artefact that keeps running. Sleeper extensions invalidate that assumption by design: the malicious payload arrives in a routine update from a publisher whose first published version was deliberately clean. Auto-update is the attack vector.
Three responses actually shift the asymmetry. First, pin extension versions in any environment that matters — developer machines accessing production systems, CI runners with deploy keys, anything with a network path to customer data. Auto-update for convenience on a sandboxed laptop is fine; auto-update on a build agent that signs releases is not. Second, behavioural monitoring on the dev-tool runtime, not just the package contents. An editor extension that suddenly starts opening TCP sockets, reading from ~/.aws, or shelling out to a curl-pipe-bash is a signal regardless of whether its first version was clean. Third, treat developer endpoints and build runners as the high-trust assets they are. Most organisations still classify dev laptops alongside ordinary user devices in their EDR policy. They aren’t ordinary user devices. They have credentials, cloud sessions, and write paths into things customers see.
The honest take. Telling developers to be careful what they install was always a low-leverage answer to this problem — the registries are too big, the publishers too anonymised, the update cadence too automated. After GlassWorm round three, it’s not even that. The control point isn’t the install moment any more. It’s the runtime.