Thanks to GlassWorm, your developer’s laptop is now the most dangerous device in your company. You’re Welcome.

Key Takeaways

• GlassWorm is an active supply chain campaign that compromised 72 VS Code extensions, 151 GitHub repositories, and over 9 million installs by weaponizing developer trust, not technical vulnerabilities
• The developer workstation has become the highest-value, lowest-scrutiny endpoint in the enterprise
• Attackers are now using AI to generate believable cover commits at scale, making static code review an insufficient defense
• Runtime behavioral detection, not perimeter controls, is the only reliable signal when the threat lives inside trusted tooling

We’ve spent the last decade hardening the perimeter. Using firewalls, Zero Trust and EDR on every endpoint. SOC analysts surviving on cold brew and adrenaline just to keep us safe. 

And then GlassWorm walked straight through the front door. Like taking candy from a baby. 

If you haven’t been following this one, here’s the short version: a threat actor spent months quietly poisoning developer tools. That means, Visual Studio Code extensions, GitHub repositories, npm packages, all with malware so invisible it literally hid inside Unicode characters your editor won’t even render. By the time the March 2026 wave was fully documented, we were looking at 72 malicious extensions, 151 compromised GitHub repos, and somewhere north of 9 million installs. The payload? A module researchers nicknamed ZOMBI, which is accurate, because it turned developer workstations into nodes in a criminal botnet, drained 49 different crypto wallets, and harvested every token and credential it could find.

Fun stuff. Really great industry we’re in, huh?

But here’s the thing: if your post-mortem stops at “malicious VS Code extension. Noted, moving on,” than you’re missing the actual story. And the actual story should keep you up at night in a way that no CVE ever has.

We built an ecosystem held together by trust and attackers figured it out.

Here’s a question nobody is asking loudly enough: How did we end up in a world where a developer installing a code formatter can detonate a supply chain incident?

The answer is trust debt and we’ve been accumulating it for years.

Every time a developer installs an extension without a security review, that’s a trust withdrawal from an account nobody is managing. Every third-party dependency your CI/CD pipeline pulls in automatically? Trust withdrawal. Every “it’s open source, someone would have noticed” assumption? Massive, compounding trust withdrawal.

We have entire vendor risk management programs for the SaaS tools finance buys. Think questionnaires, security reviews and annual reassessments. Meanwhile, your senior engineer just installed 14 VS Code extensions on a machine that has production AWS keys, GitHub tokens, and access to your secrets manager and nobody in security knows it happened.

That gap is as wide as a canyon.

What made GlassWorm particularly elegant (and I use that word with deep, begrudging respect) was how it weaponized the trust lifecycle itself. It didn’t just upload malicious extensions. No, no. That’s too obvious. It uploaded clean extensions first, let them earn installs, let them pass reviews, built a reputation and then, in a quiet update, it added a dependency link to the poison payload. The editor auto-installed the rest.

It’s the long con. Patience as an attack vector. And our detection tooling, which is largely built around looking for known-bad at the moment of ingestion, had nothing to say about it.

The developer is the new perimeter.

Was it Spider-Man’s uncle that said, “With great power comes great responsibility”? I don’t know but I think it applies here. 

I’ve said for a while now that the most dangerous endpoint in the modern enterprise isn’t the CEO’s laptop or the unpatched server in the corner. It’s the developer’s workstation.

Think about what lives on that machine:

• Cloud credentials for every environment they touch
• SSH keys, GitHub tokens, NPM tokens
• Secrets pulled from .env files that “aren’t committed to git” (they are)
• Access to CI/CD pipelines that deploy directly to production
• A rotating cast of extensions, tools, and utilities installed from the internet, often without a second thought

GlassWorm knew this. That’s exactly why it targeted developer tooling. A compromised developer machine isn’t just a compromised machine, it’s a compromised pipeline, cloud environment, even release cycle. The blast radius from a single infected workstation is staggering, which is why the ZOMBI module went straight for NPM tokens and GitHub credentials first: not to steal them, but to spread with them.

We talk a lot about lateral movement in enterprise networks. This is lateral movement through the software supply chain. Same concept, completely different playbook required to stop it.

AI just picked both sides. 

One of the most important details in the GlassWorm reporting, and the one getting the least attention, is this: researchers believe the attackers used large language models to generate the cover commits that disguised the malicious injections.

Read that again.

The 151 GitHub repositories weren’t hit with the same cookie-cutter commit. Each one received changes that were stylistically consistent with that specific project. We’re talking realistic documentation tweaks, version bumps, and small refactors that fit the codebase’s conventions. Manually crafting 151 bespoke, believable code changes across different projects is not a human-scale operation. An LLM doing it? That’s a Tuesday afternoon.

This is what AI-assisted attacks actually look like in practice. Not the sci-fi scenario where the AI is “hacking” your systems autonomously. It’s the unsexy, highly effective version: an LLM helping attackers generate convincing camouflage at a scale and speed no human team could match.

The implication for defenders is sobering. Code review, even rigorous code review, is no longer sufficient to catch this class of injection. You need behavioral detection and runtime analysis. You need to understand what your code is doing, not just what it says.

I can’t emphasize this enough; focus on runtime security because the static picture can lie or mislead. An extension that looked clean at publication is not the same extension after an update. The only source of truth is runtime behavior.

The governance gap nobody wants to talk about

I’ll make this practical, because thoughts that don’t end in action are just glorified venting. 

Most enterprise security programs have sophisticated third-party risk management for procured software. You’re likely familiar with some flow that looks like the legal team reviews contracts, security runs questionnaires, and compliance checks data handling. There are frameworks, workflows, and escalation paths.

Now ask yourself: what is your current policy for VS Code extensions?

Take your time.

If the answer is “we trust our developers to use good judgment,” I want you to really sit with that answer for a moment. Your developers are brilliant people, but they are also humans under deadline pressure who absolutely will install the extension that makes their formatter work in 30 seconds flat without reading the changelog.

Here’s what a starting governance framework actually looks like:

1. Treat developer tooling as a software supply chain. Extensions, plugins, packages, they’re all third-party software running with significant privilege. Meaning, they receive the same scrutiny. Start building an allowlist of approved extensions. It’s not glamorous, but do it anyway.

2. Enforce dependency cooldowns. Research shows a 7-14 day delay before accepting new package versions would have blocked 8 out of 10 major supply chain attacks last year. That’s an extraordinary return on a simple policy change.

3. Mandate credential rotation post-install events. If a developer installs a new tool with access to production credentials, that should trigger a lightweight review, and should trigger if anything looks off in rotation. Automate as much of this as you can.

4. Runtime is your last honest signal. In a world where attackers modify behavior post-installation and hide code in invisible characters, runtime behavioral analysis isn’t a nice-to-have. It’s the only place where what’s actually happening is visible.

5. Rotate credentials like your incident response plan depends on it. GlassWorm’s first move on a compromised machine was to harvest every token it could find and use them to spread. The blast radius of any single infection is directly proportional to how stale and over-permissioned your credentials are.

The real takeaway

GlassWorm isn’t a story about malware. It’s a story about trust infrastructure. How we built it, how we left it unguarded, and how attackers spent a year learning to climb it quietly before anyone noticed.

The software supply chain is now a primary attack surface, not an emerging one, and not a theoretical one. A primary, actively exploited one, and the threat actors operating in this space are patient, methodical, and increasingly AI-assisted.

The good news (and there is good news) is that the defenders who shift their mental model first will have a significant advantage. Perimeterless, runtime-first, supply-chain-aware security is not science fiction. The tools, practices, and urgency are finally, unavoidably, here.

So let’s get to work. The ZOMBI module isn’t going to stop just because we had a good threat intelligence briefing.

---

This post reflects my personal views and experience as the Head of Infosec & IT at Upwind, where we obsess over runtime security so your developers can install their formatters in peace. Or at least, so we know exactly what happens when they don’t. Have thoughts? Counterarguments? Evidence that I’m catastrophizing? I’m on LinkedIn. Let’s argue professionally.