iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
The November 2025 second Sha1-Hulud wave used trojanized npm package versions to run credential-stealing code during installation. Wiz reported more than 25,000 malicious GitHub repositories in a campaign snapshot, but that figure counts repositories—not affected npm packages, organizations, or computers. If a potentially compromised version ran in your project or CI environment, investigate the dependency and rotate exposed credentials; removing the package alone cannot undo credential theft.
How the npm attack worked
Wiz Research reported that attackers used compromised maintainer accounts to publish malicious versions of legitimate npm packages. The versions were uploaded between November 21 and 23, 2025. Their install configuration invoked code in npm’s preinstall lifecycle phase, so the malicious activity could begin as a dependency was installed.
- Installation launched the payload. A package’s install configuration ran
setup_bun.js, which set up or located the Bun runtime and launchedbun_environment.js. - The payload searched for secrets. Reported targets included npm tokens, GitHub credentials, cloud credentials, environment variables, and GitHub Actions secrets on developer and CI/CD systems.
- Stolen data was sent to GitHub. Wiz observed secret data placed in public repositories, including repositories belonging to users unrelated to the victim.
- Stolen credentials enabled propagation. In particular, npm credentials could let attackers publish further malicious package versions.
Wiz reported support for Linux, Windows, and macOS runners. Exposure therefore was not limited to one operating system or to developers’ personal workstations.
What the 25,000+ figure counts
The headline number describes repositories Wiz observed in its incident reporting, not the number of infected packages or affected systems. Repository visibility changed as GitHub revoked tokens and privatized or removed repositories, so the count is a time-bound snapshot rather than a current live total.
#1 Best Overall
| Reported figure | What it measures | Source and qualification |
|---|---|---|
| More than 25,000 repositories across roughly 500 GitHub users | Malicious repositories observed in the campaign | Wiz Research, November 2025 incident reporting; a campaign snapshot, not a package, organization, or machine count. |
| About 1,000 new repositories every 30 minutes | Growth during the campaign’s rapid expansion | Wiz Research, November 2025; an observed growth rate during that period, not a continuing rate. |
| More than 700 npm packages | Affected packages, with only certain versions affected | CERT-FR / ANSSI, as of November 26, 2025; some affected versions had subsequently been removed. |
The repository and package figures describe different things and must not be added together or substituted for one another. The incident reporting cited here does not establish a final authoritative count of affected packages, exposed secrets, or repositories, or confirm that all remediation is complete.
What is known about the campaign’s timing and attribution
Wiz placed the trojanized package uploads between November 21 and 23, 2025. It reported first evidence of malicious package uploads at about 03:00 UTC on November 24 and said repositories containing leaked secrets had been observed earlier that day. These are Wiz’s observation times, not proof of when the campaign first began.
Wiz said the activity resembled earlier Shai-Hulud activity, while cautioning that different actors might be involved and attribution had not been confirmed. The resemblance alone does not establish who conducted the November wave.
Free tools Windows power users keep installed
One-click scans. No signup required.
Other incident reporting also described GitHub Actions persistence and destructive fallback behavior. Treat those as reported possibilities, not actions that occurred on every infected machine.
Rank #3
How to check whether an npm project may be affected
- Identify the environment that installed dependencies. Include developer machines, build agents, and CI/CD runners, across Linux, Windows, and macOS where applicable.
- Compare package names and exact versions. Review the project’s dependency lockfiles and installed packages against the compromised-version information in CERT-FR / ANSSI’s November 2025 advisory. A package name alone is not enough: the advisory notes that only certain recent versions were affected.
- Review installation timing and execution evidence. Check whether the affected version was installed and whether installation scripts could have run. Preserve relevant logs and lockfiles while investigating.
- Inspect GitHub Actions workflows. Look for workflows you do not recognize, as CERT-FR recommends. Review account activity and repositories for suspicious changes as part of the investigation.
- Check the wider publishing and cloud footprint. Assess packages maintained by your organization and the integrity of CI platforms, and investigate use of npm, GitHub, and cloud credentials available to the potentially affected environment.
A clean view of your own GitHub repositories does not by itself rule out exposure: Wiz observed stolen data in public repositories under unrelated users’ accounts.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.What to do if a compromised version ran
- Contain further package changes. CERT-FR recommends temporarily freezing npm package updates where possible while investigating, and using versions known to be legitimate.
- Remove affected versions and validate the environment. Uninstall affected packages, check CI platform integrity, and review packages maintained by your organization. Removing a dependency is not a substitute for credential remediation.
- Rotate secrets exposed to the machine. CERT-FR advises rotating all secrets present on a suspected compromised machine. Include tokens and credentials available to the process or CI job, then check whether they were used unexpectedly.
- Clean up suspicious workflows and account changes. Remove unrecognized GitHub Actions workflows and investigate suspicious repositories, commits, or other account activity before returning systems to normal use.
- Audit dependency records. Unit 42’s September 2025 guidance for the earlier wave recommends auditing dependency lockfiles, rotating developer credentials, and reviewing GitHub accounts for suspicious repositories, commits, or workflows. This is general first-wave context, separate from CERT-FR’s second-wave alert.
Because the payload could reach developer and CI environments and credentials could enable further publishing or access, scope the response to every environment that installed the affected version—not just the package’s original project.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
