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

At a glance

What this is: Aikido reports that GlassWorm moved to a native Zig dropper that installs a malicious extension into multiple IDEs, turning one compromised extension into machine-wide editor compromise.

Why it matters: This matters because developer tooling supply chains now behave like a shared trust layer, so one extension compromise can expose secrets, sessions, and downstream code access across an entire workstation.

Context

IDE supply chain risk is the problem of trusting editor extensions, plugins, and package channels as if they were isolated tools rather than executable software with broad local privilege. In practice, that trust fails when one extension can run native code, install other payloads, and reach every editor the developer uses.

Aikido’s reporting shows why this matters to IAM and NHI programmes as well as broader cyber teams: compromised developer tooling often becomes a route to tokens, session cookies, and other secrets that behave like non-human identities in practice. Once those credentials are exposed, the blast radius extends beyond the workstation into repositories, CI/CD, and cloud services.

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 does a compromised developer extension create identity risk as well as endpoint risk?

A: Because developers often store API keys, tokens, and authenticated sessions on the same machine where the extension runs. Once those credentials are exposed, the attacker can move from local compromise to code repositories, cloud services, and automation systems without needing the endpoint again.

Q: What signs suggest an IDE compromise has spread beyond one editor?

A: Look for unexpected extension installs across multiple editors, CLI-based extension changes, unfamiliar native binaries in extension folders, and activity that does not match the user’s normal toolset. In a shared extension ecosystem, one compromised package can seed every compatible IDE on the workstation.

Q: Should teams prioritise extension allowlisting or secret rotation first after this kind of incident?

A: Secret rotation comes first if tokens or sessions may already have been exposed, because the attacker’s value lies in reused access. Allowlisting and marketplace controls are the longer-term fix, but immediate containment depends on removing any stolen credentials from circulation.

Technical breakdown

How native code in IDE extensions escapes the JavaScript sandbox

IDE extensions are often treated as lightweight add-ons, but they can bundle compiled binaries that execute outside the extension sandbox. In this case, a Zig-compiled Node native addon loads before normal extension logic and calls install() immediately, which means the malicious action runs with operating system level access rather than within the safer JavaScript runtime. That distinction matters because the trust boundary is not the extension manifest alone. It is the whole package, including binaries, helper processes, and post-install behaviour. Once native code is permitted, a plugin can become a loader, not just a feature module.

Practical implication: Treat any extension that loads native binaries as executable software and subject it to the same allowlisting and review standards as installed desktop applications.

Why cross-IDE extension ecosystems enlarge the blast radius

Many modern editors share the VS Code extension model, so compromise in one package format can spread across multiple products that developers use side by side. The dropper in this campaign enumerates installed IDEs, then installs a second-stage extension into each one through the editor’s own CLI installer. That makes the compromise environment-wide rather than editor-specific. The key risk is trust reuse across tools: once one extension is allowed to execute, it can use the local operating context to seed other installations. This is a supply chain problem, but it is also a local privilege problem.

Practical implication: Inventory every editor that shares an extension ecosystem and apply uniform trust controls, because checking only one IDE leaves the others exposed.

What second-stage payload delivery means for secrets and session exposure

The first malicious package is not the end goal. It is a delivery mechanism for a second-stage implant that can persist, beacon, and steal data after installation. A campaign like this can move from extension compromise to session cookie theft, secret exfiltration, and remote access setup without needing interactive user approval after the initial install. That creates a governance problem for IAM and NHI teams because developer endpoints often hold tokens, API keys, and federated sessions that function as machine credentials. If those are reachable from a compromised editor, the workstation becomes an identity compromise point as much as an endpoint one.

Practical implication: Assume IDE compromise can expose machine credentials and session material, and tie endpoint detection to token revocation workflows.

Threat narrative

Attacker objective: The attacker aims to turn one trusted developer extension into persistent, cross-editor compromise that can expose secrets and enable further access to code and infrastructure.

1. Entry begins when a trojanized OpenVSX extension impersonates a legitimate developer tool and ships a native dropper inside its package.
2. Credential or access abuse follows when the dropper silently fetches a second-stage .vsix from attacker-controlled infrastructure and installs it through each IDE’s own CLI.
3. Impact occurs when the second-stage implant extends compromise across multiple editors on the workstation and creates a path to secret theft, persistence, and broader access abuse.

Breaches seen in the wild

• Secrets in VS Code extensions 2025: Wiz found 550+ secrets in VS Code extensions, including publishing tokens able to push malicious updates to about 150,000 installs.
• GlassWorm campaign 2025: GlassWorm hid in VS Code extensions with invisible Unicode and stole npm, GitHub and Open VSX publishing tokens to spread.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Cross-editor trust reuse is now the real IDE supply chain weakness: the problem is no longer a single bad extension in a single editor. Once teams allow the same extension model across VS Code, Cursor, Windsurf, VSCodium, and similar tools, one compromise can propagate through the whole developer workstation. That changes the governance unit from the editor to the environment, and practitioners should treat shared extension ecosystems as one control plane.

Native helper binaries turn extensions into executable loaders: a package that looks like a routine productivity add-on can still escape sandbox assumptions through bundled native code. That matters because extension reviews that focus only on manifest data, source snippets, or permission prompts will miss the actual execution path. The control gap is not visibility alone, but whether compiled payloads are allowed to participate in trust.

Developer tooling compromise is also NHI compromise: when a malicious extension reaches session cookies, API keys, tokens, or other machine credentials, the incident crosses into identity governance. Those secrets function as non-human identities in practice, and they need ownership, inventory, revocation, and containment workflows that do not stop at the endpoint. IAM teams should assume the editor is part of the identity attack surface.

IDE supply chain risk is a workload identity problem in disguise: the attacker is not just trying to own a laptop. The deeper objective is access continuity into code hosting, cloud consoles, and automation systems through stolen developer credentials. That means detection and response have to link endpoint compromise to token rotation, federated session invalidation, and build-system review.

What this signals

IDE supply chain compromise now behaves like a local identity incident: the workstation is only the entry point. Once an editor can execute native code and seed other IDEs, the practical boundary is no longer the app but the developer identity and the secrets that identity can reach.

Extension governance needs a new named concept: cross-editor trust reuse. That is the failure mode where one approved extension model is assumed safe across multiple editors, marketplaces, and installation paths. Practitioners should expect attackers to target the shared model rather than a single product.

Aikido’s reporting shows the attack pattern is becoming more operationally mature, not just noisier: the campaign uses trojanised distribution, native execution, and second-stage installation to create persistence across the workstation. Security teams should prepare for IDE compromise to be handled with the same urgency as endpoint malware plus credential exposure.

For practitioners

• Restrict extension installation to approved sources Block direct installation from unvetted marketplaces and disable side-loading where possible. Require review for packages that bundle native binaries or spawn helper processes, because those are the paths that convert a plugin into an execution vehicle.
• Inventory every editor and extension channel Map which developers use VS Code, Cursor, Windsurf, VSCodium, Positron, and any other VS Code-compatible editor. Apply the same allowlist, telemetry, and update controls across each channel so one environment does not become the blind spot for another.
• Treat extension compromise as a credential incident If a malicious editor package is found, revoke exposed API keys, tokens, and active sessions immediately, then rotate secrets that may have been reachable from the affected workstation. Endpoint containment without identity cleanup leaves the access path intact.
• Scan for native binaries inside extensions Look for .node, DLL, and Mach-O files in extension package directories, especially where the extension impersonates a trusted tool. Native code in a plugin should be a high-priority review trigger, not a routine implementation detail.

Key takeaways

• GlassWorm’s latest technique shows that IDE extensions can become loaders for native code, not just add-ons, which expands the attack surface across the whole workstation.
• The campaign matters because a single trojanised extension can spread into multiple compatible editors and expose the developer secrets those tools can reach.
• Teams need to treat editor compromise as both an endpoint event and a credential event, with revocation, containment, and extension-source controls working together.

Key terms

• IDE supply chain: The IDE supply chain is the set of software, extensions, plugins, language servers, templates, and update channels that shape how code is written inside an integrated development environment. It includes trusted and untrusted components that can influence source code, credentials, build behavior, and developer workflows, making it a security boundary.
• Native extension binary: A compiled helper file bundled inside an editor extension that runs outside the normal scripting sandbox. Native binaries can access operating system functions directly, so they increase the trust burden on package review and make an extension’s real behaviour harder to see from metadata alone.
• 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.
• Cross-editor compromise: A failure mode where one malicious extension or package installs or influences payloads across multiple compatible editors on the same machine. It expands the blast radius because the compromise is tied to the shared extension ecosystem, not to a single desktop application.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, secrets management, and agentic AI identity. It helps security and identity practitioners connect workstation compromise to identity lifecycle controls across the wider programme.