One npm Account Publishes 964 Million Downloads Per Week. None Have Provenance.

The npm account ai publishes seven packages. Combined, they install 964 million times per week:

That's 50 billion installs per year behind a single set of npm credentials. None of them have npm provenance attestations.

Why this matters

npm provenance uses OIDC tokens from GitHub Actions instead of long-lived npm tokens. If a package has provenance, you can verify that the published code came from a specific commit in a specific repository — not from someone's compromised laptop.

Without provenance, there's no way to distinguish a legitimate release from one pushed by a stolen token. The blast radius here is nearly a billion installs per week.

This isn't theoretical. axios was attacked on March 30, 2026 through a stolen npm token — same single-publisher, no-provenance pattern. LiteLLM was hit the same way a month earlier. The Shai-Hulud worm in May 2026 exploited stolen tokens to republish 637 package versions in 39 minutes.

What makes this different from chalk or lodash

PostCSS is interesting because it's not just one critical package. It's an entire ecosystem of critical packages, all behind the same account. chalk is one package, one publisher, 432M downloads/week. Bad enough. But ai controls seven independent packages that each cross the 10M threshold.

A compromised ai token doesn't just hit postcss. It hits the CSS build pipeline (postcss + autoprefixer + postcss-nested + postcss-js), the browser compatibility layer (browserslist + caniuse-lite), and one of the most popular ID generators in the ecosystem (nanoid).

And caniuse-lite was flagged with a dormant publisher warning — 61 months of inactivity on the publishing account. postcss-nested hasn't had a release in over 12 months.

This has been fixed before

fast-xml-parser (88M downloads/week, single publisher) had the same problem. After the community raised the issue, the maintainer set up GitHub Actions OIDC publishing. Within days, version 5.9.1 shipped with SLSA provenance attestations. Then 5.9.2 added environment gates and SHA-pinned actions. The structural gap closed in under a week.

I filed an issue on PostCSS proposing the same approach.

The PostCSS maintainer disagrees — and he's partially right

Andrey Sitnik (ai) responded within hours. His argument: OIDC provenance from CI is itself an attack surface. TanStack was compromised precisely because they published from CI — the stolen token came from the CI system. His words: "CI-as-publisher increased the attack risks compared to 2FA manual publishing."

He's right that CI-as-sole-publisher shifts the attack surface rather than eliminating it. The Shai-Hulud worm exchanged OIDC tokens for publish credentials. TanStack was hit through GitHub Actions cache poisoning. Provenance proves where a build came from; it doesn't prove the CI pipeline wasn't tampered with.

His proposed alternative: Staged Releases — a newer npm feature where CI creates the release, but a human must manually approve it before it becomes the default install target. Even if an attacker compromises the CI pipeline, the malicious version sits in a holding period. No silent pushes to latest.

The honest answer is: both are better than the current state. Right now there's no provenance, no staged releases, no second factor between a stolen credential and 964 million weekly installs. Staged Releases would address the blast-radius problem directly. Provenance would at least make attacks auditable after the fact. The worst option is what we have now: nothing.

Check your own dependencies

If you want to see which packages in your project have this concentration risk:

npx proof-of-commitment

Run it in any project directory. It auto-detects your lockfile and flags packages where a single npm publisher controls more than 10M weekly downloads. That's the exact attack surface that's been exploited three times in four months.

The full PostCSS ecosystem audit data comes from Commit, which scores packages on behavioral signals rather than declared metadata.