how it works#

The loop:

1. A malicious package version is installed. Its postinstall runs.
2. The payload harvests credentials from the machine — npm tokens, GitHub tokens, cloud provider credentials — using TruffleHog-style secret scanning.
3. It exfiltrates them to a public repository created in the victim's GitHub account.
4. It uses the stolen npm token to publish trojanized versions of every package that token can publish to.
5. Those packages get installed. Go to 1.

Step four is the difference between an incident and an outbreak. Previous npm compromises required an attacker to manually obtain credentials for each package. This one propagates on its own, and its rate of spread is proportional to how many packages the compromised maintainers control.

Additional behavior observed: creating public forks of private repositories in victims' organizations, and installing a GitHub Actions workflow for persistence.

why this was inevitable#

Every precondition has been in place for years:

• Packages execute arbitrary code on install, by default.
• Publishing credentials are commonly stored on developer machines in plaintext.
• One credential frequently controls many packages.
• Nothing in the publishing flow requires human presence.

Given those four facts, a worm is not a clever attack. It is the obvious one. Security researchers have described this exact scenario in talks for the better part of a decade.

the immediate response#

npm has accelerated changes it had already announced: shorter token lifetimes, mandatory two-factor for high-impact publishing, restrictions on classic tokens, and a strong push toward trusted publishing.

Those are the right changes. They are also the changes that were "coming" for years and are now arriving under emergency conditions, which is how infrastructure security usually improves.

what to do right now#

Rotate every npm token you have, especially any on a developer machine or in a CI secret store. Assume anything that was on a machine that ran an install during the window is exposed.

Enable trusted publishing on every package you maintain. This removes the long-lived token entirely — publishing is authorized by an OIDC assertion from a specific workflow in a specific repository.

Audit your GitHub account for repositories and workflows you did not create. The persistence mechanism was a workflow file; it survives credential rotation.

Turn off install scripts everywhere you can. This remains the single highest value control and remains widely unused.

Adopt a version cooldown. Every one of these incidents has a window between publication and detection measured in hours. A 72-hour delay before adopting new versions costs you nothing and avoids nearly all of them.

the structural conclusion#

The npm ecosystem's install-time code execution is a design decision from 2010 that made sense when the registry had a few thousand packages maintained by people who mostly knew each other.

It does not make sense now, and every incident makes the argument more forcefully. Other ecosystems handle this differently — Go has no install-time execution at all, and it turns out you can build a package ecosystem without it.

The migration cost for npm is enormous and the cost of not migrating is this, repeatedly, with escalating sophistication. At some point the arithmetic flips. It may have just flipped.

Combined weekly download counts for the affected packages are on the order of two billion.

the phish#

An email from npmjs.help — a lookalike domain — claiming the account required two-factor re-verification, with a link to a credential harvesting page that also captured the TOTP code.

The maintainer has written publicly about it. The email was well-constructed, it arrived at a plausible time, and the domain was close enough to pass a quick glance.

This is worth saying clearly: the target was a competent, security-aware, long-time open source maintainer. Phishing that captures a TOTP in real time defeats the second factor. The control that actually stops this is a hardware security key or passkey, where the authentication is bound to the origin and a lookalike domain simply cannot complete it.

If you publish packages, use a passkey or hardware key. Today. TOTP is not sufficient against this attack and has not been for years.

the payload#

Browser-targeted, not server-targeted, which is unusual and clever.

The injected code hooked window.ethereum and intercepted fetch and XMLHttpRequest, watching for cryptocurrency transactions and swapping destination addresses for attacker-controlled ones — selecting a visually similar address to survive a casual glance at the confirmation dialog.

Because these packages are ubiquitous transitive dependencies of frontend build tooling, the payload had a plausible path into a very large number of shipped bundles.

Actual losses appear to have been small. Detection was fast — within a couple of hours — and most builds during the window did not pull the affected versions.

why the damage was limited#

Three things, in order:

1. Lockfiles. Most production builds resolve to pinned versions. A new malicious release does not enter an existing lockfile without someone running an update.
2. Speed of detection. The community noticed within hours. Someone diffed the published tarball against the repository and the mismatch was obvious.
3. Payload specificity. Targeting crypto wallets is narrow. A payload targeting build-time credential theft would have done far more damage.

That third point should not be comforting. The same access with a better payload would have been much worse.

the controls, again#

The same short list as every one of these:

• Phishing-resistant auth on publishing accounts. Non-negotiable.
• Trusted publishing via OIDC rather than long-lived tokens.
• Lockfiles, committed, with exact versions in production.
• --ignore-scripts in CI.
• A cooldown before adopting new versions.

None of these are new. All of them are still not universally adopted, which is the actual story.

the structural observation#

chalk adds color to terminal output. It is about a thousand lines. It has two billion weekly downloads because it is a transitive dependency of nearly everything in the JavaScript ecosystem.

A thousand-line utility maintained by a volunteer sits in the trusted computing base of a substantial fraction of the world's software, and the ecosystem's security posture depends on that person's email hygiene.

That is not a criticism of the maintainer, who did nothing unreasonable. It is a description of a system that has grown a dependency structure nobody designed and nobody can now change.

The fix is not "fewer dependencies." The fix is publishing infrastructure where a single compromised human credential cannot ship code to two billion machines. The registry has to make that impossible, because asking every maintainer to be unphishable has failed for a decade.

the payload#

The script searched for:

• npm and GitHub tokens
• SSH private keys
• Cloud provider credentials in the usual locations
• Environment variables matching credential-shaped patterns
• Cryptocurrency wallet files

It then created a public repository in the victim's GitHub account named with a recognizable prefix and pushed the harvested data to it.

Some variants additionally invoked locally-installed AI coding CLI tools with a prompt asking them to enumerate sensitive files — using the developer's own agent as a discovery mechanism. That detail is new and it is going to be studied.

the entry point#

Compromised publishing credentials. The specifics of how they were obtained matter less than the pattern: a maintainer's token, or a CI workflow with publishing rights, was reachable by an attacker.

This is the dominant supply chain attack shape. Not typosquatting, not dependency confusion, not a malicious contribution. Take over the account of a legitimate maintainer of a package people already depend on.

the controls that would have stopped it#

In order of effectiveness:

1. --ignore-scripts. The payload was in postinstall. An install that does not run lifecycle scripts does not run the payload.

npm ci --ignore-scripts

Set it in .npmrc for your CI and see what breaks. For most projects the answer is: nothing, or one package that needs a native build, which you allowlist.

2. Trusted publishing. OIDC-based publishing from a verified CI workflow rather than a long-lived token. A token that does not exist cannot be stolen. npm supports this now and adoption is the bottleneck.

3. Install cooldown. The malicious versions were live for hours before removal. A policy of not adopting a version until it is 24 to 72 hours old would have avoided this entirely, and avoids most incidents of this shape, because the window between publish and detection is short.

{ "minimumReleaseAge": 4320 }

4. Short-lived credentials. The payload harvested long-lived tokens. If your CI uses OIDC federation to get a fifteen-minute cloud credential, there is nothing durable to steal.

if you were affected#

The order matters:

1. Rotate everything the machine had access to. npm tokens, GitHub PATs, SSH keys, cloud credentials. Assume everything readable was read.
2. Check for the public repository in your GitHub account and delete it — but capture its contents first for your incident record.
3. Audit for persistence. Check ~/.bashrc, ~/.zshrc, ~/.profile, shell history, cron, launch agents, and git hooks in your repositories.
4. Review recent activity on every account whose credentials were on that machine.

Rotation before cleanup. Cleanup on a compromised machine while live credentials are still valid is how you spend an afternoon on remediation and the attacker spends it on access.

the trend#

This is one of several npm incidents this year and they are getting more sophisticated: better targeting, cleaner payloads, and now the use of local AI tooling as an attack primitive.

The ecosystem's structural weakness has not changed. A single maintainer's credentials protect a package that millions of machines install and execute automatically. Every control above mitigates; none of them fix that.

The fix requires the registry to make unattended publishing hard by default, and that is a change to how a lot of people work. It is going to happen anyway, because the alternative is this every few weeks.

The answer is zero, and the answer is zero for everyone, and the security advice industry has spent a decade pretending otherwise.

the useless advice#

"Audit your dependencies." Nobody does this. It is not a discipline problem, it is an arithmetic problem. Two thousand packages at even five minutes each is eighty engineer-days, for one project, once, and it is invalidated by the next npm update.

"Minimize dependencies." Good advice that does not scale. You are not writing your own date library, and if you did it would have more bugs than the one you avoided.

"Use a lockfile." Necessary and completely insufficient. A lockfile pins you to a specific version of the compromised package.

the useful model#

Stop trying to verify code. Start managing blast radius and time to detect.

Blast radius. Ask: if this package were malicious right now, what could it reach? A dev-only dependency that runs in CI can read your CI secrets — that is a large blast radius, and most people classify dev dependencies as low risk, which is exactly backwards. A package in your production server can reach your database. A package in your build step can modify your output artifact, which is the worst one, because it is silent.

Concretely:

• Separate the CI credentials that can publish from the ones that can test. Publishing should require a manual approval or a protected environment, always.
• Run installs with lifecycle scripts disabled where you can. npm ci --ignore-scripts for the test job costs you almost nothing on most trees.
• Do not put long-lived cloud credentials in the same job that runs npm install on a third-party tree. Use OIDC federation with a short-lived token scoped to what the job needs.

Time to detect. Most supply chain compromises are discovered within hours to days, usually by someone noticing weird network traffic or a suspicious diff. The question is whether you shipped during the window.

• Pin exact versions in production. Not ranges. 1.2.3, not ^1.2.3.
• Delay adoption. A cooldown of even 24 to 72 hours before a new version enters your tree catches an enormous fraction of real-world incidents, because the attacker's window is short and loud. Several tools now do this automatically; Renovate calls it minimumReleaseAge.
• Subscribe to advisories for the fifty packages that actually matter, not all two thousand.

the two changes with the best ratio#

If you do nothing else:

1. Turn off install scripts in CI. The overwhelming majority of npm compromise payloads are in a postinstall. This one flag defeats most of them.
2. Make publishing require a human. Trusted publishing via OIDC, provenance attestations, and a protected environment. The most damaging incidents are maintainer account takeovers, and a stolen token that cannot publish is worthless.

the thing nobody wants to say#

You are trusting hundreds of strangers, most of whom are unpaid, several of whom are burned out, at least one of whom will eventually hand their package to someone they should not have.

That trust is not going away, because the alternative is not writing software. The job is not to eliminate the trust. It is to make sure that when it is betrayed — and it will be, on a schedule — the damage is contained and you find out fast.