‘Download pumping’ joins the trust-abuse bandwagon

When appraising the legitimacy of packages in software repositories, developers and even security tools often rely on download counts. Nonetheless, the metric can be weaponized by threat actors who use automated systems such as repository mirrors and analysis bots to poison software packages and infect supply chains. 

Researchers at Tenable discovered the new technique, which they’re calling “download pumping,” while analyzing npm packages uploaded to the public registry, senior security researcher Ron Popov explained in a blog post. “We found that packages whose content got updated frequently — usually by systematically uploading many new versions for the same package — had an unusually high downloads count,” he wrote.

“We observed this technique being used deliberately in the wild for the first time in our analysis of the malicious ‘ambar-src’ package, which reached more than 50,000 downloads in three days after attackers uploaded more than 700 versions.”
—Ron Popov

Here is what you need to know about download pumping.

[ See webinar: Stop Trusting Packages. Start Verifying Them. ]

A dangerous new mutation

Diddling with download counts isn’t new. In 2021, for instance, a researcher demonstrated how download counts could be inflated by sending HTTP requests directly to the URL of a package’s tarball, or .tgz archive. Using that technique, the researcher was able to spoof nearly 1 million downloads in a week for a completely unused package.

Popov noted that the new variant, download pumping, has two advantages over HTTP version flooding. First, it provides amplification, because an attacker gains 100 to 150 automated downloads from repository mirrors for every version they upload, rather than just one download per HTTP request. Second, systematically publishing these updates populates the release history, creating a dense version log that makes the package appear actively maintained and historically legitimate.

While the Tenable team’s research focused on the npm ecosystem, Popov said the mechanics are not unique to npm. “Other package registries such as PyPI, RubyGems, and NuGet operate with similar automated infrastructure — mirrors, security scanners, and analysis bots — that pull new versions as they are published,” he said.

“Although the specific download amplification and trust metrics may differ across ecosystems, the core principle remains the same: Where automated systems react to new publications, there is potential for abuse.”
—Ron Popov

Exploiting security mantras

Download pumping exploits a security guideline that open-source developers have heard endlessly repeated. “We’ve told developers for a long time that one of the signals of a healthy tool is that it’s got a lot of users,” said Dwayne McDaniel, developer advocate at GitGuardian.

“We have this perception that if there are a lot of people touching the code, if we have a lot of visibility, then that should make it safe. That’s just not the case.”
—Dwayne McDaniel

Another security practice that can feed download pumping is rushing to install the latest fixes to a software package to make it secure, McDaniel said. “We’ve been telling developers for a long time, ‘Patch as soon as possible. If there’s a fix, you need to get it in your system so you stay protected.’ The problem is we live in a world now of supply chain attacks, where people are getting poisoned packages faster than ever.”

Download pumping works because the signals developers rely on — download counts, version history, maintenance activity — measure attention, not safety, and attention is easy to fake, said Waseem Ahmed, head of engineering at Secure.com.

Tenable researchers found that attackers pushed more than 700 versions of one malicious package — 428 of them in the first two hours — and automated mirrors, scanners, and bots inflated the number of downloads to roughly 50,000 in three days, with no real users involved, Ahmed said.

“Mirrors, bots, and scanners grab every new version the moment it’s published. That’s good behavior, but it hands attackers guaranteed traffic with no humans involved, turning defenders’ own scanners into an amplifier.”
—Waseem Ahmed

The ambar-src attackers hit 50,000 downloads in three days with zero real users because every version published triggers 100 to 150 automated downloads from mirrors and scanners, said Jacob Krell, senior director for secure AI solutions and cybersecurity at Suzu Labs. 

“Predictable system behavior is exploitable system behavior. Attackers mapped how npm mirrors and bots respond to published events and turned that into a free amplification service. The ‘vulnerable system’ here is not a server. It is the trust model.”
—Jacob Krel

The AI factor

Krell said the bigger concern for security teams is the convergence of download pumping with AI-assisted development. "”AI coding tools recommend packages based on popularity signals, and download pumping lets attackers game exactly those signals. You now have a feedback loop — inflated metrics, AI recommendations, and developer trust all reinforcing each other,” he said

“Download pumping matters because it targets the exact signal AI dev tools use to make recommendations. As AI-assisted coding scales, more developers will defer package selection to their tooling, and that tooling defaults to popularity. Attackers now have a proven, cheap method to game that signal. That loop is going to make supply chain attacks worse before the ecosystem adapts.”
—Jacob Krell

Try a little patience

Tenable’s Popov said there is no deterministic method to determine whether a new package is malicious, and so every package must be treated as if it could be malicious. “The meaningful trust signal comes after the fact, from security vendors and the open-source community actively scanning and analyzing packages once they are published,” he said.

“This is exactly why enforcing minimum-age requirements on new packages and new versions is such an effective control. A short waiting period of a few days gives the security community time to detect, flag, and remove threats from the public registry before they ever reach your environment. Organizations that consume packages the moment they are published are accepting risk that is entirely avoidable.”
—Ron Popov

Robert Russell, vice president of the Blackpoint Response Operations Center, agreed that a short waiting period before a new package reaches your environment is a reasonable and low-friction control. “The security community does a solid job of identifying and flagging malicious packages fairly quickly after publication, so giving that process a few days to run before a package is allowed into a build pipeline makes practical sense,” he said.

While it is not a complete answer on its own, Russell said, a waiting period is the kind of simple, enforceable policy that closes a real gap without requiring significant overhead to maintain.

Trust metrics such as download counts, version histories, and maintenance activity fail to protect developers because attackers can manipulate them to fake legitimacy, said Jason Soroko, a senior fellow at Sectigo, who also advocates a mandatory waiting period of several days.

“This is why organizations must layer their own defenses rather than trust the security of public ecosystems. Internal controls like version pinning and age restrictions let a company evaluate its actual supply chain risk instead of relying on easily spoofed metrics.”
—Jason Soroko

However, James Shank, director of threat operations at Expel, said that delaying package installs isn’t a solution because download pumping is a metrics interpretation problem. “Waiting a few days does not prevent the same attack; it just slows it down a bit,” he said.

And John Strand, principal at Black Hills Information Security (BHIS), said that delaying updates and patches often creates more risk than it prevents

“The overwhelming majority of software updates and open-source packages are legitimate. While supply chain attacks are serious and deserve attention, overreacting could leave organizations exposed to far more common and immediately exploitable vulnerabilities.”
—John Strand

Why layer controls matter

Shane Barney, chief information security officer for Keeper Security, said the metrics that developers and security tools have historically relied on —  including download counts, version history, and maintenance activity — were never designed to serve as trust signals. “They are convenience indicators, not security controls, and download pumping exposes that gap,” he said.

“When automated infrastructure reacts predictably to every new package publication, attackers only need to understand how the system responds to exploit it systematically. The result is a package that looks established and actively maintained before a single developer has evaluated it.”
—Shane Barney

Barney said the period between publication and detection is where risk lives. “Registries and the open-source community play a meaningful role in identifying and removing threats, but organizations that consume packages the moment they are published accept risk that is entirely avoidable,” he said.

“That reality places the burden squarely on organizations. Layering controls is the practical response, and it starts with treating software supply chain security as an enterprise responsibility rather than a developer hygiene issue.”
—Shane Barney

Enforcing minimum-age requirements on new packages and versions gives the security community time to flag and remove threats before they reach your environment, Barney said. “Least-privilege network access limits what a malicious payload can do, even if it executes successfully. Replacing long-lived credentials with ephemeral, just-in-time access reduces the blast radius when a compromise occurs.”

“None of these controls are complicated on their own, but together, they close a critical window of opportunity for attackers.”
—Shane Barney