{"id":26194,"date":"2026-09-21T15:14:52","date_gmt":"2026-09-21T23:14:52","guid":{"rendered":"https:\/\/www.palada.net\/index.php\/2026\/09\/21\/download-pumping-joins-the-trust-abuse-bandwagon\/"},"modified":"2026-09-21T15:14:52","modified_gmt":"2026-09-21T23:14:52","slug":"download-pumping-joins-the-trust-abuse-bandwagon","status":"publish","type":"post","link":"http:\/\/www.palada.net\/index.php\/2026\/09\/21\/download-pumping-joins-the-trust-abuse-bandwagon\/","title":{"rendered":"\u2018Download pumping\u2019 joins the trust-abuse bandwagon"},"content":{"rendered":"
\n
\n

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.\u00a0<\/p>\n

Researchers at Tenable discovered the new technique, which they\u2019re calling \u201cdownload pumping,\u201d while analyzing npm packages uploaded to the public registry, senior security researcher Ron Popov explained in a blog post<\/span><\/a>. \u201cWe found that packages whose content got updated frequently \u2014 usually by systematically uploading many new versions for the same package \u2014 had an unusually high downloads count,\u201d he wrote.<\/p>\n

\u201cWe observed this technique being used deliberately in the wild for the first time in our analysis of the malicious \u2018ambar-src\u2019 package, which reached more than 50,000 downloads in three days after attackers uploaded more than 700 versions.\u201d<\/em>
\u2014<\/em>Ron Popov<\/span><\/a><\/p>\n

Here is what you need to know about download pumping.<\/p>\n

[ See webinar: <\/strong>Stop Trusting Packages. Start Verifying Them.<\/strong><\/a> ]<\/strong><\/p>\n

A dangerous new mutation<\/h2>\n

Diddling with download counts isn\u2019t new.\u00a0In 2021, for instance, a researcher demonstrated<\/span><\/a> how download counts could be inflated by sending HTTP requests directly to the URL of a package\u2019s 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.<\/p>\n

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.<\/p>\n

While the Tenable team\u2019s research focused on the npm ecosystem, Popov said the mechanics are not unique to npm. \u201cOther package registries such as PyPI, RubyGems, and NuGet operate with similar automated infrastructure \u2014 mirrors, security scanners, and analysis bots \u2014 that pull new versions as they are published,\u201d he said.<\/p>\n

\u201cAlthough 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.\u201d<\/em>
\u2014<\/em>Ron Popov<\/p>\n

Exploiting security mantras<\/h2>\n

Download pumping exploits a security guideline that open-source developers have heard endlessly repeated. \u201cWe\u2019ve told developers for a long time that one of the signals of a healthy tool is that it\u2019s got a lot of users,\u201d said Dwayne McDaniel, developer advocate at GitGuardian.<\/p>\n

\u201cWe 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\u2019s just not the case.\u201d<\/em>
\u2014<\/em>Dwayne McDaniel<\/span><\/a><\/p>\n

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. \u201cWe\u2019ve been telling developers for a long time, \u2018Patch as soon as possible. If there\u2019s a fix, you need to get it in your system so you stay protected.\u2019 The problem is we live in a world now of supply chain attacks, where people are getting poisoned packages faster than ever.\u201d<\/p>\n

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

Tenable researchers found that attackers pushed more than 700 versions of one malicious package \u2014 428 of them in the first two hours \u2014 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.<\/p>\n

\u201cMirrors, bots, and scanners grab every new version the moment it\u2019s published. That\u2019s good behavior, but it hands attackers guaranteed traffic with no humans involved, turning defenders\u2019 own scanners into an amplifier.\u201d<\/em>
\u2014<\/em>Waseem Ahmed<\/span><\/a><\/p>\n

The ambar-src <\/em>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.\u00a0<\/p>\n

\u201cPredictable 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 \u2018vulnerable system\u2019 here is not a server. It is the trust model.\u201d<\/em>
\u2014Jacob Krel<\/p>\n

The AI factor<\/h2>\n

Krell said the bigger concern for security teams is the convergence of download pumping with AI-assisted development. “\u201dAI coding tools recommend packages based on popularity signals, and download pumping lets attackers game exactly those signals. You now have a feedback loop \u2014 inflated metrics, AI recommendations, and developer trust all reinforcing each other,\u201d he said<\/p>\n

\u201cDownload pumping matters because it targets the exact signal AI dev tools use to make\u00a0recommendations. 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.\u201d<\/em>
\u2014Jacob Krell<\/span><\/a><\/p>\n

Try a little patience<\/h2>\n

Tenable\u2019s 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. \u201cThe meaningful trust signal comes after the fact, from security vendors and the open-source community actively scanning and analyzing packages once they are published,\u201d he said.<\/p>\n

\u201cThis 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.\u201d<\/em>
\u2014<\/em>Ron Popov<\/p>\n

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. \u201cThe 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,\u201d he said.<\/p>\n

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.<\/p>\n

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.<\/p>\n

\u201cThis 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.\u201d<\/em>
\u2014Jason Soroko<\/span><\/a><\/p>\n

However, James Shank, director of threat operations at Expel, said that delaying package installs isn\u2019t a solution because download pumping is a metrics interpretation problem. \u201cWaiting a few days does not prevent the same attack; it just slows it down a bit,\u201d he said.<\/p>\n

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

\u201cThe 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.\u201d<\/em>
\u2014<\/em>John Strand<\/span><\/a><\/p>\n

Why layer controls matter<\/strong><\/h2>\n

Shane Barney, chief information security officer for Keeper Security, said the metrics that developers and security tools have historically relied on \u2014\u00a0 including download counts, version history, and maintenance activity \u2014 were never designed to serve as trust signals. \u201cThey are convenience indicators, not security controls, and download pumping exposes that gap,\u201d he said.<\/p>\n

\u201cWhen 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.\u201d<\/em>
\u2014<\/em>Shane Barney<\/span><\/a><\/p>\n

Barney said the period between publication and detection is where risk lives. \u201cRegistries 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,\u201d he said.<\/p>\n

\u201cThat 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.\u201d<\/em>
\u2014<\/em>Shane Barney<\/p>\n

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. \u201cLeast-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.\u201d<\/p>\n

\u201cNone of these controls are complicated on their own, but together, they close a critical window of opportunity for attackers.\u201d<\/em>
\u2014<\/em>Shane Barney<\/p>\n<\/div>\n<\/div>\n","protected":false},"excerpt":{"rendered":"

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\u2019re calling \u201cdownload pumping,\u201d while analyzing npm packages uploaded to the public registry, senior security researche<\/p>\n","protected":false},"author":4,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"colormag_page_container_layout":"default_layout","colormag_page_sidebar_layout":"default_layout","footnotes":""},"categories":[32775],"tags":[],"class_list":["post-26194","post","type-post","status-publish","format-standard","hentry","category-reversinglabs"],"_links":{"self":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/26194","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/comments?post=26194"}],"version-history":[{"count":0,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/posts\/26194\/revisions"}],"wp:attachment":[{"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/media?parent=26194"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/categories?post=26194"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.palada.net\/index.php\/wp-json\/wp\/v2\/tags?post=26194"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}