TL;DR - On 27 August 2026 the AFP announced the arrest of two West Australian men aged 21 and 23, accused of running Shai-Hulud, the self-propagating worm that phished npm and GitHub maintainers and harvested cloud keys from more than 2,500 organisations, including the LiteLLM AI-gateway compromise. The arrests are welcome and they change almost nothing about your week. The worm's tradecraft is now public, a variant family already ran through 400+ npm packages earlier in August, and the next operator does not need the original authors to keep the campaign alive. What ANZ dev teams should actually do this week: turn off npm lifecycle scripts in CI, pin third-party GitHub Actions to commit SHAs, inventory every package-publishing token older than 90 days, and make sure your rotation story revokes at the provider instead of editing a secrets file.
Two West Australians aged 21 and 23 were arrested on 27 August 2026, accused by the AFP of running Shai-Hulud, a self-propagating worm that phished npm and GitHub maintainers and harvested cloud keys from more than 2,500 organisations including the LiteLLM AI-gateway compromise. The arrests are welcome, but the tradecraft does not retire with the operators. The question for any ANZ dev team pulling packages this week is not "did we get hit" but "would we even know."
This post is about the second half of that sentence, because the first half is unanswerable for most teams. KrebsOnSecurity ties the pair to the longest-running open-source supply-chain spree on record. If your npm and GitHub footprint predates that spree, you cannot reconstruct what ran or where it sent things. You can only fix the hygiene that would have told you, and set the tripwires for the next one.
By The Numbers
| Metric | Detail |
|---|---|
| Arrests | 2 men, aged 21 and 23, Western Australia, 27 August 2026 |
| Agencies involved | AFP, FBI and WA Police (per the joint operation reporting) |
| Alleged operation | Shai-Hulud, a self-propagating worm against npm and GitHub maintainers |
| Infection vector | Phishing of maintainers, then token and session theft to republish packages |
| Organisations with cloud keys harvested | 2,500+ (per KrebsOnSecurity) |
| Best-known downstream compromise | LiteLLM AI gateway: poisoned PyPI versions, a 195 TB credential dump, 434,000 CI/CD pipelines |
| Variant activity this month | ChainDrop, analysed by Microsoft on 4 August 2026, described as a self-propagating npm worm hitting 400+ packages |
| What the arrests stop | The alleged original operators |
| What they do not stop | The technique, the tooling, and the copies |
What Shai-Hulud actually did
The mechanics matter more than the mugshots. Per the Krebs reporting, Shai-Hulud spread by phishing the people who maintain npm packages and GitHub repositories. A maintainer clicked, entered credentials on a lookalike login, and the worm walked away with the session. From there it did not need the maintainer. It used the stolen token to publish new package versions carrying the same credential-harvesting payload, so every downstream install became another shot at another developer's environment. The victim list compounds while the operators sleep.
The harvest was everything a developer workstation or CI runner has in reach: cloud keys, repo tokens, SSH keys, publishing credentials. The LiteLLM compromise sits inside this campaign as the clearest worked example. A 40-minute poisoned-publish window on PyPI put credential-scraping code into the most popular self-hosted AI gateway, and the resulting dump held credentials from thousands of organisations, including names from any enterprise shortlist. I wrote up the anatomy, and the audit I ran on my own gateway, in the LiteLLM post linked below.
The part that should hold an ANZ IT-pro's attention is the target selection. This was patience applied to the infrastructure every software team shares: the package index, the repository, the build runner. That shared infrastructure is only as strong as the weakest maintainer's password hygiene, and most maintainers are volunteers or one-person teams.
Why the arrests do not close the chapter
Arrests stop operators. They do not stop technique. Three things tell me this chapter runs past 27 August.
First, the tradecraft is documented in months of public reporting, incident writeups and vendor telemetry. Phishing maintainers, stealing sessions, republishing packages with bumped patch versions: none of it requires the original authors. It requires patience and a lookalike domain.
Second, the variant evidence already exists. Earlier in August, Microsoft published the anatomy of ChainDrop, a self-propagating npm worm that hit more than 400 packages by abusing stolen publish tokens and the preinstall lifecycle hook. My writeup of that campaign is linked below. Whether the same people or a copycat built it matters less than the sequence: the technique reproduces itself across operator groups.
Third, the credential dumps are permanent. The keys harvested during the campaign's active window are in copies held by people who were never arrested. A key that was valid, dumped, and never revoked is still an open door with nobody left to charge.
The question that matters: would we even know
Run this honestly against your own stack. If a malicious version of a package you depend on had published itself through a maintainer's stolen token six months ago, and your CI installed it quietly, what would have fired?
For most teams I talk to in the ANZ SMB space: nothing. The install log rotates in 30 days. The lockfile changed, but lockfiles change constantly, and nobody diffs them. The lifecycle script ran, but nobody audits lifecycle scripts. The token it read was a long-lived PAT with broad scopes, and nobody has ever listed, let alone age-audited, the tokens in their npm and GitHub org settings.
That is the finding: your telemetry cannot distinguish hit from not-hit. The rest of this post is the fix, sized for a small team, doable in a week of odd hours.
The this-week npm and GitHub Actions checklist
1. Turn off lifecycle scripts in CI (30 minutes). The preinstall hook is the entry point for this worm family. Add npm ci --ignore-scripts to your build jobs, and the equivalent flag for pnpm or yarn. Do it in CI first, where the trade-offs are visible, and keep a whitelist for the two or three packages that genuinely need their install scripts.
2. Enforce the lockfile (30 minutes). CI installs from the lockfile with npm ci, never npm install, never --force, never latest. A lockfile plus a code review on dependency changes is the cheapest control you own against a patched-version attack.
3. Pin third-party GitHub Actions to commit SHAs (1 hour). If your workflows say uses: someorg/someaction@v3, a compromise of that action's repository runs arbitrary code in your pipeline with your secrets in scope. Pin to the full 40-character commit SHA, and note the pin in a comment so upgrades stay deliberate. While you are in there, audit every workflow using pull_request_target, which grants fork content a privileged context.
4. Inventory publishing tokens (1 hour). List every npm access token and GitHub token your org and your developers hold. Anything older than 90 days, anything with broad scopes, anything belonging to someone who left: revoke it and mint a narrow replacement. If you publish packages, move to trusted publishing with OIDC, which exchanges a short-lived token bound to the workflow for the long-lived publish token you currently paste into a secret.
5. Make rotation mean revocation (30 minutes to plan, real work to execute). The LiteLLM follow-up had the detail that stuck with me: one organisation claimed they had rotated everything, and the old credentials still worked. Editing a secrets file is not rotation. Revoking at the provider, then updating the file, is. Write the revocation step into the runbook now, while nobody is panicking.
6. Set the two tripwires (30 minutes). First, an alert on unknown IPs authenticating with your org's tokens, which GitHub and most cloud providers emit natively. Second, a weekly diff of your own package versions against their source repositories: a version published with no matching commit or tag is the classic Shai-Hulud-shaped signal.
What the LiteLLM audit taught me that still applies
When the LiteLLM compromise landed, I ran the audit against my own gateway before writing anything: check which version actually ran, check the requester IPs in the logs, check for any sub-key I did not mint. The logs answered cleanly, which let me reason about rotation instead of performing it. The method is the transferable part. A five-person team can hold the same three questions: what exact versions did we run during the risk window, who has talked to our infrastructure from where, and can we revoke in one action. If your answers are "no idea", the checklist above is how you get to "give me ten minutes".
What this looks like for a five-person ANZ team
You do not need a SOC, an SBOM platform or a supply-chain security product to do this week properly. You need a half-day from whoever owns the pipeline. The lifecycle-script flag is one line in CI. The SHA pinning is mechanical. The token inventory is a settings page and a calendar reminder for quarterly repeats. The tripwires are two alerts on telemetry you already pay for.
The scale argument cuts the other way too. At enterprise size, a compromised pipeline means 400,000 credentials in a dump. At five-person size, it means your cloud account, your customer repos and your deployment keys, which is the entire business. The worm does not check headcount before it installs.
Frequently Asked Questions
Were Australian organisations among the victims?
The victim list per the Krebs reporting is global, and the credential-to-organisation mapping in the dumps was incomplete, with many keys carrying no identifying context. Treat "probably, and unprovable either way" as the honest working answer, and let it push you toward the token inventory rather than the archive search.
Is npm safe now that arrests have been made?
No. The technique is documented, a variant family ran the same month as the arrests, and the dumps outlive the operators. npm is as safe this week as the hygiene of the maintainers you depend on and the controls you run locally. The checklist above is the local part.
We never publish packages. Are GitHub Actions still in scope?
Yes. You consume third-party actions, and those run inside your workflows with your secrets reachable. Pin to commit SHAs, audit the privileged triggers, and scope the workflow token down. Consumption is exposure here.
How do we check whether our tokens were in the dumps?
You mostly cannot, and anyone selling certainty is guessing. The workable move is exposure-based: any long-lived token that predates the campaign window gets revoked and replaced, with narrow scopes, on the assumption it is public.
What is the one change if we only do one?
The lifecycle-script flag in CI. It is one line, it blocks the entry point this worm family uses, and it forces every future install-script surprise to announce itself.
Further Reading
- KrebsOnSecurity - Two Alleged TeamPCP Hackers Arrested in Australia (27 Aug 2026) - the arrests and the Shai-Hulud tradecraft, the primary source for this post
- The Hacker News - GitHub Actions security disclosure in open-source CI/CD tooling (28 Aug 2026) - the same-week open-source signal on GitHub Actions exposure
- LiteLLM supply-chain leak: how I checked my own home gateway - the downstream compromise anatomy, the 195 TB dump, and the audit method
- ChainDrop worm: 400 npm packages self-propagated - the variant family Microsoft analysed on 4 August, and the lifecycle-script defence
- GitHub docs - Security hardening for GitHub Actions - the vendor's own guidance on SHAs, tokens and privileged triggers
Mathew Clark Founder, SecureInSeconds Currently: explaining to my family why a worm named after a science-fiction sandworm has a mugshot, then checking the age of the one npm token I found in my own dotfiles.
