Python’s CVEs triple in a year as PyPI removes 60% more malware

November 2026. 175 incoming GitHub Security Advisories received by the Python Software Foundation since January, against 41 for all of 2025. 3×. That is how much Python and pip CVEs have grown year over year. 60%. That is how much more malware PyPI now publishes and removes. Why it matters: the substrate under most of the DevOps toolchain is changing its risk profile, and the fix will not come from the language itself — it will come from how teams consume their dependencies.

A number the maintainers can no longer keep up with

Both figures trace back to one person: Seth Larson, the PSF’s Security Developer-in-Residence, whose position is funded by the Alpha-Omega foundation. In late October 2026 he published the CVEs-per-year curve: between 2007 and 2024 the language stayed below 20 CVEs a year. 2025 broke that ceiling, and 2026, extrapolated over the full year, lands around 65.

That is only one face of the problem. Core developer Hugo van Kemenade documented the rest in his post “Security: line goes up”: incoming GitHub Security Advisories went from 18 in 2024 to 41 in 2025, then 175 in the first half of 2026 alone. The email report flow follows the same slope, around 50 threads a month.

Reading these curves as a simple “more bugs” story would be wrong. Part of the rise is work being done better: the PSF formalized a security policy, defined the PSRT (Python Security Response Team) through PEP 811, and pushed researchers toward the GHSA channel. But even discounting that measurement bias, the 2026 slope has no precedent, and methodology alone does not explain it.

PyPI, the target that got too big to ignore

The second number lands harder for an SRE: malware removed from PyPI is up 60%. PyPI is the registry through which every pip install flows on millions of CI machines, containers and developer laptops. Malware that spends a few hours there can poison thousands of builds before anyone flags it.

This is not a Python-only phenomenon. Daniel Stenberg, the curl maintainer, reported as early as June 2026 that curl’s CVEs had tripled too. The common thread is not the language, it is the position: the Internet’s foundational libraries are now the highest-yield attack surface per unit of effort, because one compromised package propagates downstream to every consumer.

The dominant mechanisms remain typosquatting and maintainer account compromise — two vectors a hand-run dependency audit will never catch. The PSF is responding with automation: PyPI’s autonomous quarantine, which removes suspicious packages without human intervention, is being scaled precisely to absorb this volume.

The response is funded — but it is not your job

Faced with this load, the PSF announced in late October 2026 the hiring of a second Security Developer, Brett Smith, funded by an “ecosystem security” grant from Anthropic — the same company that has been investing in the Python ecosystem’s security since December 2025. The role will absorb remediation, CVE-data publication as a numbering authority, and malware removal from PyPI.

That is good news, and an instructive one. Open-source security funding now rests on grants from AI companies — a dependency worth noting, and one that is currently producing concrete results. What it does not produce is a reduction of risk in your pipelines: nobody but you will lock your dependency file.

The minimal check is two commands, run in CI rather than by hand:

pip install pip-audit
pip-audit --requirement requirements.txt

pip-audit cross-references your dependency tree against the CVE and PyPI advisory databases. It is not a policy, but it turns a global signal into an actionable list.

What this changes for a DevOps team

The underlying shift fits in one sentence: the cost of implicit trust in dependencies rose by an order of magnitude in a year. Three reflexes change as a result:

• Pin by hash, not by version. A ==1.2.3 does not protect against a package being re-published under the same number. Hash pinning (pip freeze --require-hashes) closes that vector.
• Scan in CI, not after deploy. A pip-audit at the end of the pipeline costs seconds and stops contamination before it reaches an internal registry.
• Generate an SBOM for every artifact. The Cyber Resilience Act and your customers are starting to require it; it is also the only way to answer “what is running in this image?” during an incident.

The tipping point is simple: as soon as a team ships more than one Python application in production, the overhead of hash pinning and automated scanning is negligible next to the cost of malware slipping through a foundational package.

AI accelerates the problem before it solves it

It is worth naming the elephant: the 2026 surge is not independent of the rise of code-generation models. Two forces stack. The first is offensive: models are now used to find flaws at a speed no human can match — the same dynamic that tripled curl’s CVEs. The second is accidental: AI-generated code introduces, on average, more bugs per line than human code, and review does not keep up with the thousands of lines submitted every day.

The paradox is that the defense flows through the same companies accelerating the offense. Anthropic, which funds the PSF’s second Security Developer, is also one of the leading producers of generated code. That is not a scandal; it is a funding reality: open-source ecosystem security now rests on AI lab budgets.

For a DevOps team, the practical consequence is this: risk is no longer measured by the code you write, but by the code your tools write for you. Dependency review has to treat generated code as unaudited third-party code — because that is exactly what it is.

The supply chain is no longer a metaphor

The tripling of CVEs is not a Python-only story: it is a structural shift across open source. Registries — PyPI, npm, Maven Central — concentrate millions of packages, a tiny fraction of which are actively maintained. When the security load explodes, it lands on volunteer maintainers with no budget and no team.

That is why the question is no longer “should we scan our dependencies?” but “who funds the defense?”. The current answer — grants from Anthropic and Alpha-Omega — is fragile by design: it depends on the goodwill of a handful of players. A team that wants robustness cannot delegate it to that generosity: it locks its dependency files and generates its SBOMs, full stop.

Verdict

If you run Python in production, the 60% rise in PyPI malware and the tripling of CVEs are not statistics to comment on — they are reasons to lock your chain down today. Pin dependencies by hash, run pip-audit in CI and generate an SBOM per artifact — in that order, without waiting for the next alert. PyPI’s autonomous quarantine and Anthropic’s grants absorb the volume on the maintainer side, but neither covers your pipelines: the one line of defense you still own is your dependency file.

References

• Hugo van Kemenade — “Security: line goes up” (October 2026)
• Python Software Foundation — “Announcing new Security Developer at the PSF” (October 2026)
• Python Software Foundation — “Anthropic invests in Python” (December 2025)
• Slashdot — “Python’s CVEs Triple. Anthropic Funds a New Security Developer” (November 8, 2026)
• pip-audit — official documentation