API worms are here, and they’re not going anywhere.

Twice now, Shai-Hulud has leveraged exposed API keys — and yes, even TruffleHog — to discover those keys, move laterally through them, and self-propagate. Four years ago I wrote about the inevitability of API worms, and the short version is: this is only the beginning. Now that we have real-world proofpoints showing these things can work — and can cause serious damage — we should expect to see a lot more of them.

An API worm is, at its core, a worm that doesn’t need to compromise hosts the traditional way. Instead of relying entirely on malware execution, it uses APIs and API keys to spread between accounts, services, and data lakes. Host malware may still be part of the campaign, but it’s no longer required for initial propagation. Access begets access.

How API Worms Spread

Picture this:

1. An attacker finds an API key on GitHub.

2. That key has access to S3.

3. Inside that S3 bucket sits another API key granting access to Jira

4. Jira’s support tickets contain multiple companies’ API keys (this has happened — see the Cloudflare breach involving their keys in Okta’s ticketing system).

5. One of those keys unlocks an Artifactory instance.

6. That Artifactory instance contains build artifacts — some of which contain more credentials — and also allows malware to be published into the supply chain.

This is not theoretical. This is exactly the kind of multi-platform daisy-chain Shai-Hulud already attempted, just with a smaller ecosystem. Nothing prevents the next iteration from being bigger, faster, and more aggressive.

The Key Problem (Literally)

If you need a reminder of the scale here:

• Millions of live API keys are sitting on public Github.

• Thousands more sit on GitLab, BitBucket, Huggingface, and Postman.

• Thousands more are exposed in open S3 buckets.

• And the list goes on and on.

Every leaked key falls into one of two buckets:

• Data access (storage, logs, analytics, tickets, internal documents)
  → Which almost always leads to more keys.

• Compute access (CI/CD, build systems, code repositories, artifact stores)
  → Which provides the capability to find or deploy more keys.
  
  

Once a worm gets rolling, each platform becomes a lookup table for the next platform. Every integration becomes a new infection pathway. Every company becomes collateral damage in someone else’s leak.

We Need to Clean Up the Keys — Now

There’s just no sugarcoating it: we are sitting on a massive, interconnected pile of exposed credentials, and worms love nothing more than interconnected piles of credentials.

Right now, nothing is stopping someone from building a more advanced Shai-Hulud — one that supports dozens of SaaS platforms, hunts keys across artifacts automatically, exploits inter-company ticket leaks by design, and self-propagates faster than defenders can manually rotate credentials.

If Shai-Hulud was the proof of concept, the next one will be the lesson.

The Path Forward

The fix isn’t glamorous:

• We have to clean up exposed keys — everywhere.

• We have to rotate keys every time they’re exposed

• We have to build systems that assume these keys will leak.

TruffleHog was designed to help find these exposures. But finding them is only half of the equation. The other half — rotation, removal, and systemic prevention — is now more important than ever.

API worms aren’t coming. They’re already here. And the only thing standing between us and the next one is whether we take exposed credentials seriously before someone else’s worm does.