No. A download count in a headline measures fetches of a package over some period, usually across all its versions. It does not say how many fetched the bad version, ran it, or run it today. Use the number as context, then measure your own exposure directly.
What a headline number usually is
When a story says a compromised package gets "millions of downloads a week", the figure is almost always a total for the package name. It tells you the package is popular. It does not tell you:
- How many of those downloads were the bad version.
- How many were automated, such as CI runs and mirrors fetching the same file again.
- How many reached a machine that executed the code.
A popular package makes a story bigger. It does not make your exposure bigger. Your exposure depends on whether your systems installed the bad version in the window.
How npm's public numbers work
npm publishes a documented download counts API. A few details from its documentation matter when you read a story:
- Raw log data is processed once a day, soon after UTC midnight, so the newest day is not available immediately. A page read at 5 p.m. US Pacific in winter may still lack today's data.
- You can query a package over a period such as last week, last month or a date range, with a day by day range endpoint.
- Counts for a specific version are only available for the previous seven days, through a separate per version endpoint.
That last point is the useful one. If someone quotes a total for the package, you can ask for the per version figure for the last week and see how much of the traffic was the version in question.
curl -s https://api.npmjs.org/versions/some-package/last-week
curl -s https://api.npmjs.org/downloads/range/last-week/some-package
For a scoped package, the slash in the name needs to be percent encoded, as in @scope%2Fname.
Why even the per version number is not your exposure
A per version download count is closer to the truth, and it is still a count of fetches. Automated systems fetch repeatedly. A single company's CI might account for thousands of downloads a day. The count says nothing about which machines ran the code or what data they could reach.
So use it for a rough sense of scale and keep your attention on your own systems.
What to measure instead
- Which of your repositories, images and machines reference the package, and at which version?
- Did anything install the bad version inside the window? See the post on building the exposure window.
- What could that environment reach, such as tokens, cloud credentials and production data?
Those three answers decide your response. A headline number does not appear in any of them.
A worked example
Imagine a headline says a package with "over two million weekly downloads" shipped a malicious update. You use the package in three repositories.
You run the per version query for the last week and find that the bad version, 7.2.0, had about 60,000 downloads. The rest of the traffic went to earlier versions. The headline number was true and nearly useless: only a small share of fetches were the bad version.
You then look inward.
- Repository A pins 7.1.9 with a lockfile. Not exposed.
- Repository B uses a range and a lockfile that resolved 7.2.0 on Tuesday morning. Exposed.
- Repository C uses the package only in a test folder that never ships, but its CI installed 7.2.0 on Tuesday. The CI environment holds a deploy token. Exposed through CI.
Three repositories, two exposed, none of which the headline number could have told you. Your answer came from your own inventory and build history.
Three common misreadings
| Misreading | Why it fails |
|---|---|
| "Two million downloads means two million victims" | The figure is for all versions and includes automated fetches |
| "Few downloads means little risk" | A small package inside your build can still reach your secrets |
| "Downloads dropped, so it is over" | A drop can reflect the removal, not the cleanup on your systems |
The pattern is the same in each case: a number about the world is being used to answer a question about your systems.
Why the timing detail matters
The npm documentation notes that daily counts land after UTC midnight, so a query for today usually returns nothing and a query for the last day usually means yesterday. If you are trying to line up a spike with a timeline in a write-up, remember that day boundaries are in UTC. A spike on a given date may include downloads from the previous evening in the US.
The documentation also lists limits on range queries, such as 18 months of data for a single package and a start date of January 10, 2015. These rarely matter during an incident, but they explain empty responses when you ask for something outside the range.
What to say when someone quotes the number
A calm, useful reply: "That is the total for the package. The relevant number is how many of our systems installed the bad version, and we are checking that now. So far, two of three repositories resolved it." It redirects attention to the question that decides your response.
When download counts are useful
Counts have a place. They help you gauge how widely a story will spread, which affects how many questions you will get from customers and colleagues. They help you notice an unusual spike for a quiet package. And per version numbers, while limited, can show whether the bad version was fetched at all in the last week.
Use them for context, not for scoping. Scoping is a list of your own systems with evidence, not an estimate about the internet.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how every component and version gets an entry, since that is the list you search first.
Safeguard's SBOM and dependency scanning builds that per project inventory, which is the data you need for question 1.
Quick check
Is a high weekly download count a sign my exposure is high?
No. It shows popularity. Your exposure depends on whether your own systems installed the bad version.
Where can I see downloads for one version?
npm documents a per version endpoint, but only for the previous seven days. Record the numbers early if you want them in your notes.
Can download counts show whether my own systems were hit?
No. They count fetches across the registry. Your lockfiles, build logs and install history are the evidence about your systems.
Sources
Last reviewed: 19 October 2026.
