- Active npm supply chain attacks leveraged phishing and maintainer account takeovers to push trojanized releases.
- Self-propagating "Shai-Hulud" malware stole secrets and republished compromised packages at scale.
- GitHub is enforcing stronger controls: 2FA for local publishing, short-lived granular tokens, and trusted publishing.
- Ecosystem guidance emphasizes token rotation, dependency audits, and adopting FIDO-based 2FA and OIDC-backed workflows.
Open source powers modern development, but its scale and openness also create a wide attack surface where npm security must constantly evolve to keep pace with adversaries.
In recent weeks, researchers and registries have detailed a series of npm-focused incidents that blend social engineering, credential theft, and malicious package publication—culminating in a wormable campaign capable of spreading via trusted maintainers’ own release workflows.
Recent wave of attacks against the npm ecosystem
Multiple reports describe targeted phishing aimed at npm maintainers, followed by the rapid push of new versions carrying post-install payloads that execute on developer machines and CI systems.
One campaign, tracked as “Shai-Hulud,” delivered a multi-stage worm that scoured environments for secrets, abused GitHub APIs, and attempted to self-propagate by publishing tainted packages under compromised accounts.
Security teams and registries reacted quickly: GitHub removed hundreds of affected packages and added blocks tied to malware indicators of compromise, steps that disrupted further spread across the registry.
Separate investigations linked the tactics to earlier incidents (including the “S1ngularity”/Nx workflow theft and a wave of updates to popular packages), highlighting a clear escalation from isolated credential theft to automated supply chain abuse.
- Trusted packages were updated with post-install scripts designed to harvest tokens and exfiltrate data.
- Compromised accounts published new versions, multiplying risk across projects and downstream dependencies.
GitHub’s roadmap to harden npm publishing
To curb token abuse and contain wormable malware, GitHub outlined changes that narrow the publishing attack surface and raise the bar on maintainer authentication.
- Local publishing will require two-factor authentication (2FA), with no bypass option.
- Granular tokens used for publishing will have a maximum lifetime of seven days.
- Legacy classic tokens will be deprecated and publishing via tokens will be disallowed by default.
- TOTP-based 2FA will be phased out in favor of FIDO/WebAuthn methods.
- Trusted publishing will be expanded, with more eligible CI/CD providers.
These measures will be introduced gradually, with documentation and migration support to help maintainers adjust workflows safely while minimizing disruption; consulte el impacto de GitHub Copilot en el desarrollo para entender cambios en flujos de trabajo.
How the Shai-Hulud campaign operates
The threat actors typically start by spoofing npm or related services to phish a maintainer, then use stolen credentials to publish an update that runs a malicious post-install sequence.
Once executed, the payload enumerates local environment variables, configuration files, npm settings, and cloud keys; it also abuses GitHub APIs to list accessible repositories, create branches, and drop a malicious workflow that automates secret collection and persistence.
Investigators observed the use of secret-scanning utilities (for example, TruffleHog) to widen the net of harvested credentials before clearing traces. Data was staged to attacker-controlled endpoints and, in some cases, pushed into a newly created public repo named “Shai-Hulud” under the victim’s account.
The worm’s defining trait is self-replication: if npm tokens are found, it attempts to publish altered packages, effectively turning maintainers’ privileges into an engine for exponential spread.
- Key behaviors: post-install abuse, automated GitHub API operations, and repository workflow injection.
- Threats include cloud account compromise, IP theft via full repo mirrors, and lateral movement across organizations.
Scope and impact
Research teams have cataloged hundreds of affected releases across diverse projects, including widely used libraries with millions of weekly downloads, increasing the blast radius for unsuspecting consumers.
Telemetry and incident response findings indicate organizations in North America and Europe were among the most exposed to related payloads, with risks ranging from cryptojacking and data theft to disruption in build and deployment pipelines.
Related npm security findings to watch
Analysts also flagged fezbox, a short-lived npm package that embedded a QR code-based payload technique to fetch and execute JavaScript for grabbing browser credentials from cookies—an unusual form of steganographic evasion.
While many apps avoid storing passwords in cookies today, the method underscores how quickly attackers iterate on obfuscation and delivery within package ecosystems.
Trusted publishing: a broader shift across registries
Trusted publishing—recommended by open source security groups—replaces long-lived API keys with short-lived, OIDC-backed identities from CI systems, reducing token sprawl and exfiltration risk.
First seen on PyPI and later adopted by RubyGems, crates.io, npm, and NuGet, this approach brings cryptographic provenance and stronger guarantees about how and where a package was built.
What maintainers can do now
There are immediate steps maintainers and teams can take to reduce exposure while registry-level defenses roll out and improve the overall security posture of their projects.
- Adopt trusted publishing with OIDC and remove long-lived API tokens from CI/CD.
- Enable and enforce FIDO/WebAuthn 2FA for npm, GitHub, and CI providers.
- Review and lock down publishing permissions; remove unused tokens and accounts.
- Audit dependencies (especially recent updates) and pin versions to reduce supply chain drift.
- Rotate npm, GitHub, and cloud credentials; assume any secret present on a developer machine could be exposed.
- Scan for suspicious workflow files (for example, .github/workflows/shai-hulud-workflow.yml) and unexpected branches.
Indicators and hunting ideas
Teams can bolster detection with shared indicators and queries, tailoring them to local tooling while avoiding noisy false positives.
- Example SHA-256 observed in the wild: 46faab8ab153fae6e80e7cca38eab363075bb524edd79e42269217a083628f09
- Webhook artifact reported: hxxps://webhooksite/bb8ca5f6-4175-45d2-b042-fc9ebb8170b7
- Watch for creation of public repos named “Shai-Hulud” under contributor accounts.
- Look for post-install script execution patterns and sudden dependency churn.
Sample hunting cues (adapt for your platform): monitor connections to webhooksite domains; flag writes of shai-hulud-workflow.yml; alert on command lines invoking “trufflehog” in build agents; and review recent repo changes that introduce CI workflows without approval.
Timeline highlights
Late August saw a targeted breach tied to a workflow flaw that leaked a publishing token and led to trojanized releases; early to mid-September brought a broader strike involving popular npm packages, and then the Shai-Hulud campaign with worm-like propagation and aggressive secret harvesting.
Throughout, coordinated response from registry operators and security vendors removed compromised versions, blocked known IoCs, and accelerated plans to mandate stronger auth and provenance for npm publishing.
These incidents show how quickly a threat actor can turn maintainer trust into distribution for malicious code, and why the ecosystem is moving toward FIDO 2FA, short-lived credentials, and CI-attested releases to cut off entire classes of attacks.
