debug Has 653M Weekly Downloads. One Publisher Hasn't Touched It in 8 Years. They Can Still Push a Release.

npm audit checks for known vulnerabilities. It doesn't check whether someone who hasn't published in eight years can still push a release to a package your project installs every build.

We scanned the publisher lifecycle of top npm packages and flagged every account that (a) has current publish scope and (b) hasn't published to that package in 12+ months.

The findings cover 2.6 billion weekly downloads.

The data

Every one of these accounts can run npm publish right now and push code that lands in your node_modules/ within minutes.

Why this matters

The npm token model is straightforward: if you have publish access, you can publish. There's no "inactive" state, no timeout, no re-authentication required after years of dormancy. A token from 2017 works in 2026.

That means every dormant account is a credential target. The attacker doesn't need to find a zero-day. They need to find a .npmrc on an old laptop, a token in a GitHub Actions secret that was never rotated, or a phished email on an account the owner hasn't checked in years.

This is exactly how the axios attack worked in March 2026. One stolen npm token. One push. 113 million installs per week compromised.

debug: the 105-month case

debug has 4 historical publishers. Two had their access revoked: tjholowaychuk (TJ Holowaychuk, the original author) at 146 months inactive, and thebigredgeek at 109 months.

The third, tootallnate (Nathan Rajlich), published 19 versions between 2014 and 2017. His last debug publish was September 2017. His access was never revoked.

The active maintainer, qix- (Josh Junon), published most recently. But tootallnate's account has had publish access to 653 million weekly downloads for eight years without using it.

Someone cleaned up tjholowaychuk and thebigredgeek. They missed tootallnate.

What you can do

If you maintain a package:

1. Audit who has publish access: npm access ls-collaborators <package>
2. Revoke access for anyone who hasn't published in 12+ months
3. Enable npm Staged Publishing — it adds a review step before versions go live

If you depend on these packages:

1. Pin versions in your lockfile and review lockfile diffs in PRs
2. Run npx proof-of-commitment --file package-lock.json to check your full tree for dormant publisher risk
3. Add a CI gate: npx proof-of-commitment --fail-on=critical

How we found this

Commit tracks publisher lifecycle for every scored package: total historical publishers, who's currently active, who has access but hasn't published, and who was revoked. The dormant-with-access flag was added in v1.35.0.

Scan any package: npx proof-of-commitment debug cross-spawn yargs

Or check the full reports for all packages in this article.