a token on a developer laptop is only as dangerous as the one package it publishes

what everyone assumed

No source quotes a victim stating this belief, so the title is a constructed proxy for it. It is a reasonable one. A publish token is created for a task: to ship a package. It sits on the laptop or in the pipeline that ships it, and its reach feels like the reach of that package.

The platform’s own later changes point at the same assumption. According to GitHub’s changelog, classic npm tokens never expired, and write-enabled granular tokens used to have no maximum lifetime, with a default of 30 days. A token with no end date on a machine you own looks like a small risk, because the machine is yours and the token only does one job.

what happened

The first wave began on 14 September 2025. ReversingLabs names the package rxnt-authentication 0.0.3, published at 17:58 UTC that day, as the first known compromised package, and Socket’s timeline agrees. How the first maintainer accounts were taken is unknown. ReversingLabs says the nature of the initial compromise is not known, and phishing or vulnerable GitHub Actions are only candidates. Unit 42 tentatively suggests a phishing campaign imitating npm that asked developers to update their MFA login options. That is a hypothesis.

A malicious version ran a script on install. According to Socket, Wiz, Unit 42 and GitHub’s own description, the script ran TruffleHog and read environment variables, the .npmrc file, cloud keys and GitHub tokens from the machine it landed on.

Then the worm used the npm token as a publisher. Socket and StepSecurity describe code that validated stolen npm tokens and used them to publish trojaned versions of up to 20 other packages of the same maintainer. GitHub says the worm worked through compromised maintainer accounts. This is why the sources call it a worm, and why a developer’s token became the way the next packages got infected: the credential collected on one machine did the publishing for the next set of packages.

Stolen GitHub tokens had a second use. According to Wiz and Socket, the worm created a public repository named Shai-Hulud holding the secrets, pushed a workflow that posted secrets to webhook.site, and made private repositories public with the description “Shai-Hulud Migration”.

The largest burst came on 16 September 2025. At 01:14 UTC, according to Socket, a large set of packages, including the CrowdStrike-scoped ones, was published from an account named crowdstrike-publisher.

A second wave followed on 24 November 2025. It was called “Shai-Hulud 2.0” and “Sha1-Hulud: The Second Coming”. Wiz says it may be a different actor. This time the script ran at preinstall, installed Bun, registered a self-hosted runner named SHA1HULUD, tried cloud secret managers and destroyed the home directory if it could not exfiltrate, as described by Wiz, Unit 42 and Aikido. Wiz tested the runner backdoor but did not see it used in real attacks. Aikido reports that the worm now republished up to 100 npm packages, compared with 20 the first time.

PostHog’s own post-mortem shows one route in. On 18 November 2025, a malicious pull request (a proposed code change) ran in an automated workflow and sent out the access token of a bot account. On 23 November, the attacker pushed a changed workflow that dumped all of the repository’s Actions secrets, including the npm publish token. PostHog says a static-analysis alert about that risky workflow had been dismissed when the workflow change was merged on 11 September 2025. Per Aikido, PostHog’s packages were published at 04:11 UTC on 24 November, and PostHog found and removed them, and revoked its publish tokens, at 09:30 UTC. PostHog says it has since moved to pnpm 10, which skips install scripts by default.

how it surfaced

GitHub says it received the report of the first wave on 14 September 2025. On 15 September, StepSecurity published its post on @ctrl/tinycolor and further packages. On 22 September, GitHub published a plan for the registry: granular tokens that last 7 days, local publishing with 2FA, trusted publishing, and deprecation of classic tokens and TOTP codes. On 23 September, CISA published its alert, citing more than 500 compromised packages, and advised users to pin to versions from before 16 September. GitHub’s own count was also 500+, and Socket’s indicator list ran to 526.

For the second wave, Datadog counts at least 796 unique npm packages in its analysis updated on 4 December 2025, and reports the last infected package it observed at 18:00 UTC on 24 November. Wiz and Unit 42 both report over 25,000 malicious repositories. Wiz says GitHub started removing related repositories and revoking leaked tokens at about 09:00 UTC on 26 November.

The platform changed in response. GitHub’s changelog entry dated 9 December 2025 says all npm classic tokens were permanently revoked, npm login now gives a 2-hour session token, write-enabled granular tokens have a maximum of 90 days, and new packages get 2FA by default. That changelog page is marked retired, so check npm’s own documentation for the rules in force today. On 23 December 2025, GitHub’s roadmap for the next two quarters listed bulk OIDC onboarding, more OIDC providers and staged publishing with MFA approval. Those were listed as what comes next, and the post does not say they were delivered.

None of the sources used here gives a financial total, and none records a regulator, court or fine. CISA’s alert is guidance.

A publish token is a distribution channel, and the worm used it as one.

Pick one token your team holds and write down everything it can publish or reach. If that list is longer than the job the token was made for, the list is your exposure.

The same family of credentials appears in other incidents here. The tj-actions page covers a hijacked CI action that printed secrets, npm tokens among them, into build logs, and the Codecov page covers CI environment variables sent to an attacker. Shai-Hulud picks up where those stories stop, with the question of what a thief does with a publish token. The XZ Utils page shows how a maintainer role can be gained over a long period, and here the first-wave entry point is still unknown. For the underlying habits, see the token guide, the GitHub identity guide and the service accounts guide.