Over the past year or so, the number of malicious packages has grown beyond anyone’s wildest expectations. The rapid, 10,000%+ increase has caused scaling challenges in systems like ProGet, which are designed to detect and block these harmful packages. For ProGet, this translated to timeouts and slowness when processing data updates from Inedo Security Labs.

While it’s a relatively easy problem to address, it did require that we make some relatively major, behind-the-scenes changes in ProGet 2025.20, our February 6th, 2026 maintenance release. It also meant we needed to scale back on malicious package data updates for older versions of ProGet. Neither of these were ideal.

This blog post serves as a combination of release notes and technical background on these changes. Overall, the changes pose very little risk, and if you have any issues upgrading, you can simply rollback.

A Quick Primer on Malicious Packages

Unlike a package with unintentional vulnerabilities (i.e. defects) that may open your applications to security exploits if used in a certain way under certain conditions, a malicious package is always unsafe to use. That’s because it was intentionally crafted to cause harm.

For example, consider the colorama and colourama Python packages. One is designed to help users “make ANSI escape character sequences work under Windows”. The other is a malicious package that does the same thing, but also checks the Windows clipboard for bitcoin addresses. Can you tell which is which?

When we first designed ProGet’s malicious package handling, nearly all malicious packages worked like that. Some clever attacker would clone the original package under a similar-sounding name and then carefully sneak in some malicious payload.

Rise of the Malware Bots

While those kinds of packages still exist, the overwhelming majority of malicious packages are basically bot-created spam that no one will ever see, let alone use. These packages don’t rely on typos, but instead random, “package-sounding” names generated by some LLM.

The contents of these packages are little more than a script that downloads a cryptominer or other malware. It’s absolutely trivial to detect and, within hours of being published, these low-effort spam packages are deleted by another bot. And since there’s no real skill or cost involved in creating these kind of attacks, enterprising cybercriminals will just give it a shot.

While there’s no real harm posed by these kinds of malicious packages, they do need to be treated just like all other malicious packages — and that means, added to our malicious packages list.

Malicious Package Handling in ProGet

Although vulnerabilities and malicious packages are totally different things, they’re kind of similar from a technical standpoint. And, since there were only about 2,000 malicious package entries when we designed the system back in 2022, it seemed like a reasonable shortcut to represent them internally in the same manner. That way, we could use the same datafile from Inedo Security Labs to update the internal ProGet database.

200,000+ malicious package entries later, we came to regret that decision. The original logic just wasn’t designed for that many entries – and that meant the update job would often timeout and fail. While we’ve optimized the update logic in ProGet a few times over the years, it still requires updating to a newer version of ProGet.

Although updating ProGet usually involves just a few clicks, many users simply prefer to not update very often, or can’t due to organizational policies. And for those users, we decided to stop adding malicious package entries to the vulnerability database updates.

Malicious Package Database

ProGet 2025.20 and later now includes a separate malicious package database that contains the names/versions of hundreds of thousands of known packages.

By default, this database will be updated on a nightly basis during the Vulnerability Database Updater scheduled job.

Malicious Packages & Compliance

In ProGet 2025.20, we also took the opportunity to change how ProGet responds when a malicious package is discovered. Now, both download blocking and noncompliance will be automatic and cannot be configured through policies.

If a malicious package is detected, no further analysis (license compliance, etc.) will be performed — it’s simply noncomplaint and cannot be used. The only way to work-around this is to bypass policy-checking on the package in general.

In practice, this means that:

• if a malicious package is included in a Build, the build will always be considered noncompliant
• if a malicious package is found in a feed, it will trigger notifiers as appropriate
• if a user tries to download a malicious package, it will be blocked

Next Steps: Don’t Rush to Update

While it’s true that malicious package updates will only be available in ProGet 2025.20 and later, this doesn’t mean you need to rush to upgrade. Just follow our When to Upgrade your Inedo Product guidance as you would otherwise.

Realistically speaking, the vast majority of malicious packages are spam that were deleted within hours from being published. They’re about as dangerous as “Nigerian prince inheritance scam” emails in your spam folder.

On the other hand, sophisticated malware packages will continue to pose a real threat. But even with those, there’s no guarantee that anyone will detect them until after they’ve been downloaded by a few hundred victims. The only real protection against these types of malicious packages are blocking Recently Published Packages.