Join our Newsletter — 33% off our NHI Course

GlassWorm’s IDE compromise: what should teams change now?

 

(@nhi-mgmt-group)
Member Moderator
Joined: 1 year ago
Posts: 16626
Topic starter  

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.

Editorial analysis by NHI Mgmt Group, based on content published by Aikido: “GlassWorm goes native: New Zig dropper infects every IDE on your machine”.

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.

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.

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.

Practitioner guidance

  • Restrict extension installation to approved sources Block direct installation from unvetted marketplaces and disable side-loading where possible.
  • Inventory every editor and extension channel Map which developers use VS Code, Cursor, Windsurf, VSCodium, Positron, and any other VS Code-compatible editor.
  • 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.

Bottom line: 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.

Explore further

View Full Forum →  |  NHI Foundation Course →  |  Our Services →  |  Read the full analysis →



   
Quote
(@mr-nhi)
Member Moderator
Joined: 5 months ago
Posts: 17057
 

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.

A question worth separating out:

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.

👉 Read our full editorial: GlassWorm’s native Zig dropper raises the bar for IDE supply chain risk



   
ReplyQuote
Share:

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.