Notifications
Clear all
Topic starter
02/08/2026 11:48 am
TL;DR: GlassWorm has evolved from malicious packages into a native Zig dropper that installs a second-stage extension across multiple IDEs, including VS Code, Cursor, Windsurf, VSCodium, and Positron, according to Aikido. The campaign shows how developer tooling supply chains can be used to plant persistent access and reach every editor on a machine, not just one extension host.
NHIMG editorial — based on content published by Aikido: GlassWorm goes native, new Zig dropper infects every IDE on your machine
By the numbers:
- When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.
Questions worth separating out
Q: What breaks when a malicious IDE extension can load native code?
A: Native code inside an extension breaks the assumption that the extension sandbox contains runtime behaviour.
Q: Why do compromised IDE extensions create more risk than ordinary endpoint malware?
A: They sit inside trusted development workflows and often run with access to source code, tokens, and cloud tooling.
Q: What do security teams get wrong about extension marketplace scanning?
A: They often treat marketplace approval as proof of runtime safety.
Practitioner guidance
- Inventory every installed IDE and extension source Build an endpoint inventory that includes VS Code, Cursor, Windsurf, VSCodium, and any other editor using the same extension model.
- Detect native addon loading in extensions Add endpoint detections for extension packages that load compiled .node or equivalent binaries at activation time.
- Rotate secrets after any IDE compromise Assume local tokens, API keys, and browser sessions may have been exposed if a malicious extension was installed.
What's in the full article
Aikido's full article covers the operational detail this post intentionally leaves for the source:
- The exact extension filenames, hashes, and release location used in the GlassWorm campaign.
- The binary-level installation flow that shows how the dropper enumerates IDEs and force-installs the second-stage package.
- The specific indicators of compromise that help a SOC or endpoint team confirm whether a workstation was affected.
- The article's step-by-step detection guidance for Aikido users and non-users.
👉 Read Aikido's analysis of the GlassWorm Zig dropper and IDE compromise →
GlassWorm’s IDE compromise: what should teams change now?
Explore further
02/08/2026 12:58 pm
Native extension execution is now a workstation identity risk, not just a malware risk. Once an IDE extension can load native code, it can access the same local artefacts that developers rely on for day-to-day work. That includes tokens, browser sessions, SSH material, and cached credentials. The governance gap is the assumption that extension trust stops at the marketplace listing, when the real risk starts at runtime. Practitioners should treat extension execution as a privilege boundary.
A few things that frame the scale:
- The average estimated time to remediate a leaked secret is 27 days, despite 75% of organisations expressing strong confidence in their secrets management capabilities, according to The State of Secrets in AppSec.
- Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap, according to The State of Secrets in AppSec.
A question worth separating out:
Q: How should teams respond after discovering a trojanized IDE extension?
A: Contain the workstation, remove the malicious extension, and rotate any secrets that may have been available on the device. Then review repository access, cloud audit logs, and session activity for signs that stolen tokens or cookies were reused before the endpoint was rebuilt.
👉 Read our full editorial: GlassWorm’s native Zig dropper raises the bar for IDE supply chain risk
