Stripe and Google Cloud Storage Are Both CRITICAL on npm

The stripe npm package processes payments for millions of businesses. It has 14 million downloads per week and one npm publisher: a service account called stripe-bindings.

If someone compromises that account's credentials, they publish a malicious version to every npm install in every CI pipeline that depends on stripe. This is not a theoretical risk. The axios attack in March 2026 followed the same pattern: one publisher, stolen credentials, 97 million machines exposed.

The audit

I ran five infrastructure packages through Commit's behavioral audit:

Package	Score	Publishers	Downloads/wk	Risk
next	93	4	39.7M	—
@aws-sdk/client-s3	92	2	27.5M	—
prisma	88	2	13.4M	—
stripe	86	1	14.0M	CRITICAL
@google-cloud/storage	86	1	11.2M	CRITICAL

Two of the five are CRITICAL. Not because Stripe or Google have bad security practices — they don't. But because npm's publish model concentrates access in a single credential.

What CRITICAL means

A package is CRITICAL when it has a single npm publisher and more than 10 million weekly downloads. This is the attack surface that the axios, LiteLLM, and event-stream attacks exploited. The attacker doesn't need to find a vulnerability in the code. They need one credential.

Stripe also has hasDangerousWorkflow: true from the OpenSSF Scorecard, meaning its GitHub Actions configuration has patterns that could be exploited. Combined with a single publisher, this creates two independent attack paths.

What's NOT at risk

Stripe the company has strong security infrastructure. Their API, dashboard, card processing — those run on systems they control. The risk is the npm distribution channel. The stripe npm package is the SDK that 14 million weekly installs pull into their applications. A malicious version runs in your CI pipeline and your production servers — not Stripe's.

The same applies to @google-cloud/storage. Google's cloud services are locked down. The npm package that wraps them isn't — it's one compromised google-wombot account away from 11 million weekly poisoned installs.

The structural fix

Two paths out:

1. Add a second npm publisher. next has 4 publishers. @aws-sdk/client-s3 has 2. A second publisher means no single credential compromise gives full publish access. This costs nothing.

2. Enable npm Trusted Publishing. OIDC-based provenance ties every published version to a specific GitHub Actions run. No long-lived tokens to steal. fast-xml-parser adopted this in June 2026 after the same single-publisher pattern was flagged.

Compare: prisma has 13.4M downloads/week and 2 publishers. Not CRITICAL. The difference is one npm owner add command.

Check your own dependencies

npx proof-of-commitment --file package.json

Or paste packages into the web audit. The CRITICAL flag shows which of your dependencies have this concentration risk.