GitGuardian identified an evolved variant of the Shai-Hulud worm in early August 2026, searching 469 locations across developer environments for credentials. The previous version checked 189.

What 469 counts

It counts places the malware looks, not credentials it found, and not machines infected.

That distinction is going to be lost immediately, because 469 reads like a haul. It is a capability figure — the size of the search, published by researchers who read the code, and it says nothing about how many developers were reached or what came back.

No infection count has been published. No indicators of compromise were included. There is no npm statement in the reporting.

So the honest reading: the worm got more thorough, and nobody outside GitGuardian can say how well it did.

The additions are the signal

Where it looks has always been the interesting part, because the list is a map of what is worth stealing at a given moment.

The original set was the classic developer environment: .env files, shell history, package manager configuration. The new variant adds CI/CD tooling, cloud configuration, and — the one worth stopping on — AI tool settings.

An AI tool's configuration file holds API keys for model providers. Those keys are billable, they are frequently scoped generously because nobody expects a model endpoint to be a lateral movement path, and they are stored by tools that were written recently and fast. A year ago they were not on anybody's target list. They are on this one.

If your organisation has been issuing model provider keys to developers on the assumption that the worst case is a surprise invoice, this is the week to revisit that.

It does not break trust. It borrows it.

The mechanism is worth being precise about, because "supply chain worm" invites the wrong mental picture.

Shai-Hulud does not compromise npm, forge signatures or break a trust relationship. It harvests credentials and then uses them as intended. Publishing credentials are the dangerous class: with them, the worm pushes a package through the normal, trusted, fully authenticated channel, and everything downstream verifies correctly because everything downstream is correct.

Which means the detection question is not "was this package tampered with" but "did the person whose key signed it actually mean to". The same shape turned up in the JSCeal analysis this week: nothing cryptographic failed, an attacker simply held something they should not have.

What to do

  • Treat model provider API keys as production credentials. Scope them, rotate them, and put them somewhere a file-scanning worm does not reach.
  • Get credentials out of .env files on developer machines. That has been the advice for years and this is the reason it keeps being given.
  • Rotate npm publishing tokens, and require two-factor authentication for publish. Publishing credentials are the ones that propagate.
  • Check CI/CD variable stores against what actually needs to be there. The new search list includes them because they are usually generous and rarely audited.
  • Do not read 469 as a breach figure. It is the size of a search.

What is not established

  • How many machines are infected. No figure published.
  • Which organisations were affected.
  • How many credentials were actually taken, as opposed to looked for.
  • Whether the distribution vectors have changed.
  • Attribution. None offered.