TL;DR: A new Shai-Hulud worm variant in SAP npm packages is stealing developer credentials, cloud secrets, and GitHub tokens, with over 2.2M monthly downloads affected and more than 1,200 attacker-created repositories used for exfiltration, according to OXSecurity. The attack shows how supply-chain malware turns CI/CD and developer trust into a secrets-harvesting pipeline.
NHIMG editorial — based on content published by OXSecurity: A Mini Shai-Hulud has Appeared, a self-propagating worm targeting SAP developers in npm packages
By the numbers:
- OX Security identified over 1,200 repositories created by the attacker containing stolen developer credentials.
- @cap-js/sqlite has monthly downloads of about 1M, with weekly downloads around 260k.
Questions worth separating out
Q: How should security teams handle exposed developer secrets after a supply chain attack?
A: They should assume the secrets are reusable until proven otherwise, revoke them immediately, and trace where they were accepted before the compromise was contained.
Q: Why do npm supply chain attacks create such a large blast radius?
A: Because install-time code can inherit access from developer laptops and CI runners, which often already hold cloud tokens, GitHub credentials, and automation secrets.
Q: What do teams get wrong about key rotation after credential theft?
A: They treat rotation as a cleanup task instead of a control that limits the attacker’s window of use.
Practitioner guidance
- Inventory package install trust paths Map where npm installs can execute with access to GitHub tokens, cloud credentials, or build metadata.
- Shorten the lifetime of developer and runner credentials Rotate GitHub, npm, and cloud tokens on a fixed cadence and immediately after any suspected exposure.
- Watch for attacker-controlled repository creation patterns Search for public repositories containing the string A Mini Shai-Hulud has Appeared, then hunt for suspicious results directories and timestamped JSON blobs.
What's in the full analysis
OXSecurity's full report covers the operational detail this post intentionally leaves for the source:
- Package names and fixed versions for the affected SAP npm modules.
- The repository naming pattern and the "results" directory structure used for exfiltration.
- The malware's credential collection flow across GitHub Actions and cloud secret stores.
- The article's immediate response guidance for developers and security teams.
👉 Read OXSecurity's analysis of the Shai-Hulud worm in SAP npm packages →
Shai-hulud in SAP packages: what should IAM and NHI teams do?
Explore further
Secret sprawl in developer tooling is now an identity problem, not a software hygiene problem. This worm works because package installs, build runners, and cloud SDK defaults can all inherit usable credentials at the point of execution. Once those credentials exist in the workflow, the attacker does not need a fresh login path, only a way to collect and export what is already trusted. The practitioner conclusion is that developer environments must be governed as NHI attack surfaces.
A question worth separating out:
Q: Who is accountable when a compromised package exposes cloud or developer secrets?
A: Accountability sits with the teams that own maintainer credential governance, release controls, CI/CD hardening, and secret rotation. If a compromised dependency touched systems with sensitive credentials, the response must include revocation, reconstruction, and post-incident access review. Software supply chain incidents are identity incidents, not just build failures.
👉 Read our full editorial: Shai-hulud worm in SAP npm packages exposes secrets at scale