GlassWorm’s native Zig dropper raises the bar for IDE supply chain risk

At a glance

What this is: This is an analysis of GlassWorm’s move to a native Zig dropper that compromises multiple IDEs and installs a second-stage malicious extension.

Why it matters: It matters because developer workstations often hold source code, tokens, and session credentials, so IDE compromise can become an identity and secrets exposure problem as well as a malware problem.

By the numbers:

• Only 44% of developers are reported to follow security best practices for secrets management, exposing a significant developer behaviour gap.
• When AWS credentials are exposed publicly, attackers attempt access within an average of 17 minutes and as quickly as 9 minutes in some cases.

👉 Read Aikido's analysis of the GlassWorm Zig dropper and IDE compromise

Context

GlassWorm is a supply chain attack against developer tooling, not just an extension ecosystem problem. The key failure is trust in software that runs inside the IDE, loads native code, and can silently pivot into other installed editors. In identity terms, that means a workstation can become a container for secret theft, session replay, and delegated access abuse if local controls are weak.

The article shows why IDE compromise now sits at the intersection of endpoint security, application supply chain risk, and non-human identity governance. Extensions can carry the same operational value as service accounts or API keys when they expose source code, tokens, and browser session material. That makes this a practical identity security issue for teams that manage developer credentials, secrets, and access pathways.

Key questions

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. Once a compiled binary runs, it can access local files, processes, and command execution paths with the host’s permissions. That turns a simple add-on into a platform for persistence, propagation, and secret theft.

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. That means a single malicious extension can steal secrets and influence software supply chain paths before conventional controls notice. The risk is amplified when organisations assume developer tooling is outside identity governance.

Q: What do security teams get wrong about extension marketplace scanning?

A: They often treat marketplace approval as proof of runtime safety. In practice, static review only captures the package state at submission time, while the real risk may emerge after restart, update, or code obfuscation. Teams should use scanning as one control, not the control that closes the case.

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.

Technical breakdown

How a trojanized IDE extension executes native code

The malicious extension loads a compiled binary during activate() before normal extension logic runs. Native addons execute outside the JavaScript sandbox, so they inherit the host process permissions and can access the file system, installed applications, and local command execution paths. In this case, Zig was used to build platform-specific binaries for Windows and macOS, which helped the dropper blend into ordinary extension packaging while expanding what the payload could do at runtime.

Practical implication: treat native code inside extensions as a separate trust boundary and inspect bundled binaries before allowing installation.

How the dropper moves from one IDE to many

The binary enumerates editor installations that share the VS Code extension format, including VS Code, Cursor, Windsurf, VSCodium, and Positron. It then uses each editor’s own CLI installer to force-install a second-stage .vsix file, which means one compromised extension can become a propagation mechanism across every compatible IDE on the host. That is a local supply chain worm pattern, not a single-app compromise.

Practical implication: inventory every IDE on developer endpoints and restrict extension installation paths, not just the primary editor.

Why the second stage matters for identity and secrets

The second-stage extension is the real operational risk because it is designed for persistence, secret exfiltration, and downstream control. Once a malicious extension is installed, it can access tokens, browser cookies, and other local artefacts that often function as non-human identities or session credentials. This is why IDE compromise can quickly become cloud compromise, repository compromise, or SaaS account compromise if those secrets are reused or cached locally.

Practical implication: assume endpoint code execution can expose identities and rotate any secrets that may have been present on the device.

Threat narrative

Attacker objective: The attacker aims to turn one infected developer workstation into a durable launch point for secret theft, persistence, and wider access across IDEs and connected services.

1. Entry occurs through a trojanized OpenVSX extension that impersonates a legitimate developer tool and loads a native binary at activation time.
2. Escalation happens when the native dropper uses local OS-level access to discover every compatible IDE installed on the machine and silently force-installs the second-stage package.
3. Impact is achieved through persistence, secret theft, and broader workstation compromise across multiple editors, creating a pathway to repository and account abuse.

Breaches seen in the wild

• Code Formatting Tools Credential Leaks — Widely used code formatting tools cause massive credential and secrets leaks in enterprise environments.
• Hard-Coded Secrets in VSCode Extensions — 500+ VSCode extensions expose hardcoded tokens and credentials creating massive developer supply chain risk.

Read our 52 NHI Breaches Analysis report for a comprehensive view of breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

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.

GlassWorm shows a local supply chain worm pattern that security teams are underestimating. The dropper does not need to break the IDE ecosystem once and stop. It uses the host itself to spread into every compatible editor, which means endpoint scope and software inventory matter as much as package vetting. This complicates conventional application security because the malicious code is not limited to one repository or one package manager. Practitioners should re-evaluate endpoint controls, extension allowlists, and developer workstation hardening together.

Credential exposure windows are becoming shorter while remediation cycles remain too slow. Developer environments are full of high-value secrets, but the incident response model still assumes there is time to detect and clean up after exposure. That assumption weakens when malware can harvest tokens and session material immediately after installation. In NHI terms, the real failure mode is unmanaged secret persistence on endpoints. Practitioners should reduce what is stored locally and shorten the time between compromise detection and credential rotation.

Developer tooling now needs the same governance discipline applied to other non-human identities. Extensions, build tools, and automation agents increasingly hold the same practical power as service accounts because they can act with inherited trust. That makes lifecycle controls, provenance checks, and revocation paths part of identity governance, not optional hygiene. The named concept here is IDE identity spillover: when compromise of one developer tool exposes the identities and secrets attached to the entire workstation. Practitioners should govern IDEs as identity-bearing software.

From our research:

• 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.
• If a malicious IDE extension can expose secrets in minutes, the operational gap is not discovery alone but the full secret lifecycle, as covered in NHI Lifecycle Management Guide.

What this signals

IDE identity spillover will become a more common operating assumption for developer security teams. Once extension runtimes can reach multiple editors, the endpoint itself becomes part of the identity perimeter, and secrets governance has to follow that perimeter rather than stop at the repository boundary. The practical response is tighter extension governance, faster revocation, and fewer local credentials retained on devices.

The shorter the exposure window, the less value there is in slow, manual response. If a workstation compromise can surface credentials immediately, then rotation, session invalidation, and endpoint containment need to be coordinated as one workflow. That aligns with the control logic in the NHI Lifecycle Management Guide and with the risk patterns described in the 52 NHI breaches Report.

For practitioners

• 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. Block unsanctioned marketplaces and require review for extensions that bundle native binaries or request broad filesystem access.
• Detect native addon loading in extensions Add endpoint detections for extension packages that load compiled .node or equivalent binaries at activation time. Those files should trigger review because native execution bypasses the JavaScript sandbox and materially changes the risk profile.
• Rotate secrets after any IDE compromise Assume local tokens, API keys, and browser sessions may have been exposed if a malicious extension was installed. Rotate the secrets that lived on that workstation, invalidate active sessions where possible, and review downstream access logs for reuse or abuse.
• Limit local credential persistence on developer devices Reduce how long credentials remain on endpoints by preferring short-lived tokens, hardware-backed authentication, and brokered access paths. The goal is to keep workstation compromise from turning into long-lived identity exposure.

Key takeaways

• GlassWorm demonstrates that IDE extensions can act as a propagation mechanism, not just a delivery vehicle for one payload.
• Developer workstations are identity-rich environments, so extension compromise can expose the secrets that power cloud, code, and SaaS access.
• Teams should govern IDEs, extensions, and endpoint secrets as one control problem, with fast rotation and tighter installation controls.

Key terms

• Native addon: A native addon is compiled code that a runtime loads directly, usually to perform tasks that JavaScript or other sandboxed code cannot do efficiently. In an extension context, it expands the attack surface because the addon can operate with host-level permissions outside the usual language sandbox.
• Ide Extension Supply Chain: The set of trust relationships that govern how IDE extensions are built, published, updated, and executed inside developer environments. In practice, it is a software supply chain problem because a trusted plugin can become an execution path for code, credentials, and downstream compromise.
• Identity spillover: The secondary risk created when a breach supplies attackers with context they can reuse against people or systems outside the original compromise. In shared platforms, messages, metadata, and organizational relationships can fuel phishing, impersonation, and operational confusion long after the initial access is contained.
• Second-stage implant: A second-stage implant is payload code delivered after initial access to extend control, persistence, or collection. It often performs the attacker’s main objectives, such as credential theft or lateral movement, while the first stage focuses on delivery and concealment.

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.

👉 Aikido's full post covers the infection chain, indicators of compromise, and detection guidance.

Deepen your knowledge

The NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, secrets management, and workload identity. It gives security and identity practitioners a common control vocabulary for reducing exposure across modern access paths.