Supply-chain tool
Is that package’s download count real?
A high npm download count is the single most common reason a developer — or an AI coding agent — decides a dependency is safe. It is also cheap to manufacture. Publishing a package in hundreds of rapid-fire versions makes registry mirrors and scanners fetch it over and over, and the public counter climbs into six figures with nobody actually using it. PumpCheck reads the shape of the traffic instead of the total, and tells you what the number is really worth.
Free, one package at a time. Reads the public npm registry and downloads API — no account, no token.
A worked example
One package we measured on 16 September 2026 advertised 848,015 downloads for the previous 30 days. Its daily series was: 0, 12, 8, 494,004, 16, 26, 22, 16, 19, 22, 0, 11, 0, 0, 112, 233, 33, 0, 0, 34 … One day carried 99.9% of the month. The sustained rate implies about 615 real downloads — the public figure overstates genuine pull-through by roughly 1,300x. Nothing about that requires anyone to have acted in bad faith, and we make no claim that anyone did. It simply means the number cannot be used as evidence of adoption.
Audit your whole dependency tree
Checking one package at a time is fine when you already have a suspect. The audit is for when you don’t: paste a package.json or package-lock.json and every dependency in it gets checked, ranked worst-first. $299, one time, no subscription.
Your file is never stored. We read the dependency names to price and pin the audit, then keep only a hash of that list — you paste the same file back once on the results page to unlock it.
Use it from your coding agent
PumpCheck is available as an MCP server, so an agent can check a dependency before it adds it. Point your client at:
https://www.edgethirteen.com/api/mcp/pumpcheck
It exposes one read-only tool, check_npm_download_trust, with the same free limits as this page.
Frequently asked
What is download pumping?
It's a deception technique documented publicly in 2026 by Tenable and ReversingLabs. An attacker publishes a package in hundreds of rapid-fire versions — one campaign pushed 428 versions in its first two hours. Every new version causes registry mirrors, security scanners and analysis bots to fetch the package again, and npm counts those fetches as downloads. Within days the public counter reads tens or hundreds of thousands with no real users at all. The inflated number is the attack: developers read a high download count as proof a package is safe and widely used.
How does PumpCheck tell a pump from genuine popularity?
It ignores the headline number and looks at the shape of the traffic. A genuinely used package is downloaded steadily: its busiest day is typically 1–4x its median day, and carries roughly 3–8% of the month. A pumped package's traffic collapses into a spike — we measured one package whose busiest day was 24,098x its median and carried 99.9% of the month. PumpCheck reports median-day × 30 as a spike-resistant estimate of sustained usage, and separately checks for recent version floods.
Does a flagged result mean the maintainer did something wrong?
No, and PumpCheck is deliberately written never to say that. Registry mirrors, CI pipelines and security scanners produce exactly the same signature innocently, and a big launch day can too. The finding is about the metric, not the person: it says this download count is not evidence of adoption, so you should verify the package some other way before depending on it.
Why does this matter more now than it used to?
Because dependency choices are increasingly made by AI coding agents, which pull in packages at machine speed and have no instinct for whether a number looks earned. A metric that can be manufactured for a few dollars is now feeding decisions no human reviews.
Isn't this what Socket or Snyk already do?
Those tools are excellent and solve a different problem: they inspect what a package's code does — install scripts, obfuscation, known CVEs, suspicious permissions. PumpCheck doesn't read code at all. It audits the trust signal itself, which is the thing the attack targets. They're complementary; run both.
What does the paid audit add?
The free check does one package at a time. The $299 audit takes your package.json or package-lock.json, checks every dependency in it — including transitive ones — and returns a worst-first ranking of the packages whose download counts don't hold up. One-time, no subscription. Your file is never stored: the audit is pinned to a hash of your dependency list.
Where does the data come from?
Two public, unauthenticated npm endpoints: the downloads API for the last 30 days of daily counts, and the registry document for the version publish timestamps. No API key, no account, and no language model — it's deterministic arithmetic, so the same package gives the same answer.