Mini Shai-Hulud Turns Package Publishing into a Wormable Trust Path
A coordinated compromise of npm and PyPI packages shows how trusted publishing, CI caches and maintainer identities can combine into an automated supply-chain attack.
Security researchers reported a new “Mini Shai-Hulud” campaign on 11 May involving trojanised packages in the npm and Python ecosystems. The affected projects included packages associated with TanStack and other well-known organisations, giving the malicious releases a potentially large downstream audience.
The campaign abused software-delivery trust rather than relying on an obvious lookalike package. Researchers described theft or misuse of publishing identities, GitHub Actions cache poisoning and OpenID Connect tokens used for trusted publishing. CERT-EU reported that more than 160 npm and PyPI packages were affected.
Trusted publishing reduces one risk, not every risk
OIDC-based publishing removes long-lived registry tokens from a repository. That is a worthwhile improvement. It does not make the workflow safe if an attacker can alter the workflow, poison a cache or execute code in a job that is allowed to request a publishing token.
The unit of trust is therefore the entire release path: maintainer account, branch protection, workflow file, reusable actions, runner, cache, package registry and provenance record. A weakness in any one of them can produce an authentic-looking malicious release.
Start with containment and exposure
Teams using potentially affected packages should not limit their review to the application repository. A malicious install script may read CI secrets, cloud credentials, package tokens and developer configuration, then use them to spread.
The immediate workflow is:
- identify affected package names and versions in lockfiles and build logs;
- stop or isolate builds that executed them;
- preserve runner, registry and audit logs;
- rotate credentials available to the job, including short-lived trust relationships;
- inspect unexpected releases, workflow edits, repository creation and cache changes;
- rebuild from a trusted point with clean runners and verified dependencies.
Do not assume that removing one package completes the response. The interesting question is what the package could access while it ran.
Harden the release path
Pin third-party actions by commit, protect release workflows with code-owner review and separate pull-request testing from privileged publishing. Restrict when a workflow may mint an OIDC token and bind the registry’s trusted-publisher policy to an exact repository, workflow and environment.
Caches should not cross trust boundaries. Untrusted pull requests must not be able to seed artefacts later consumed by a privileged release. Use ephemeral runners where possible and keep production credentials out of generic build jobs.
Package consumers can reduce blast radius with lockfiles, controlled update windows, internal mirrors or allowlists, and install-time network restrictions. Provenance and signatures help, but only if policy verifies them and the signing workflow itself is protected.
Expect copycats
Researchers warned that public availability of attack code encouraged imitation. Defenders should therefore monitor for the technique, not only the original indicators. A different package name or exfiltration domain can leave the underlying workflow unchanged.
Mini Shai-Hulud is a useful correction to a common assumption: replacing static secrets with federated identity is the start of release security, not the end. A publish button has become a distributed production system and must be defended like one.
