What happened
Security researchers say the GlassWorm campaign has evolved by abusing Open VSX extension relationships, including dependency and extension-pack behavior, to spread malicious payloads through what appears to be benign tooling.
The campaign reportedly expanded with dozens of malicious extensions and related ecosystem activity.
Why this is different
Instead of shipping clearly malicious logic in a single package, this pattern can:
- seed trust with initially low-signal extensions,
- pull in malicious components later through dependency links,
- reduce detection by splitting behavior across packages and updates.
For engineering teams, this increases the chance that routine extension installs introduce hidden risk.
Who is most exposed
- Developer workstations with broad extension install permissions.
- CI/CD runners that inherit developer tooling or tokens.
- Teams depending on open-source extension ecosystems without strict allowlists.
Defensive actions to prioritize
- Enforce extension allowlists for IDEs in managed environments.
- Review extension dependency chains during intake, not just top-level packages.
- Rotate developer and CI tokens where suspicious extension activity is found.
- Monitor for unusual process launches and outbound traffic from editor processes.
- Tighten repository protection to reduce malicious or stealthy dependency introductions.
Bottom line
Supply-chain abuse is moving beyond obvious malware packages. Treat developer extensions as privileged software and apply the same scrutiny you use for production dependencies.