In May 2026, attackers compromised hundreds of open-source packages on npm and PyPI in 5 separate worm campaigns. Security teams patching against the first compromise pulled the second one in with the next routine dependency update.
This is what enterprise security teams are dealing with right now. The standard playbook still says one thing in response, and has said it for the last 20 years. Patch faster than attackers can weaponize a vulnerability. Stay current on every release. Pull dependency updates aggressively. Shorten the patching cycle.
That advice was the right answer for 20 years. It is the wrong answer now.
The "patch faster" playbook rests on three assumptions about how the patching cycle actually works. Assumption one, that vulnerabilities get discovered at human speed. Assumption two, that the open-source packages your team pulls from are mostly trustworthy. Assumption three, that a signed patch is what it claims to be. All three of those assumptions broke in the last 6 weeks.
Discovery is no longer at human speed
In April 2026, Anthropic released a model called Claude Mythos Preview. Mythos finds vulnerabilities in real codebases on its own, with no human guidance needed after the initial prompt.
Anthropic restricted early access to a consortium called Project Glasswing. The Glasswing partners include Apple, Amazon, JPMorgan, Palo Alto Networks, Microsoft, Google, NVIDIA, Cisco, CrowdStrike, and Broadcom.
By May 22, 2026, the Glasswing consortium had reported 1,596 new vulnerabilities across 281 open-source projects, all of them found in a single month using Mythos.
Of those 1,596 vulnerabilities, only 97 have been patched upstream.
A few specific examples from the consortium's work give a feel for what Mythos can do. Mythos identified a 17-year-old vulnerability in FreeBSD's NFS server and built a working multi-stage exploit for it on its own. That exploit chain is the kind of work a senior exploit developer might spend weeks constructing. In a separate test against a Firefox JavaScript engine, Mythos produced 181 working exploits. Anthropic's previous-generation model produced 2 working exploits against the same engine.
Mythos finds vulnerabilities roughly 100 times faster than the previous generation of model. The maintainers who fix those vulnerabilities work at the same speed they always have. Mythos files bug reports faster than maintainers can ship patches.
Don't get me wrong. Some of the Mythos hype is overstated. I think there is a case to be made that anyone who pointed a publicly available model at a real codebase today would find vulnerabilities humans had missed.
What an AI model can find on its own today is far beyond what one could find a year ago. That alone is enough to break the assumption that vulnerability discovery happens at human speed.
In July, the Glasswing consortium plans to publish the remaining Mythos-discovered vulnerabilities that are not patched by then. Based on the current ratio of disclosures to patches, that public release is likely to be somewhere in the low thousands of critical or high-severity bugs in widely used open-source software.
The upstream is no longer trustworthy
On May 11, 2026, a threat group using a worm called Mini Shai-Hulud compromised the TanStack family of open-source packages. The attack chained three techniques together. First, the attackers triggered Pwn Request, a vulnerable GitHub Actions workflow pattern that lets pull requests from a forked repository execute code with the privileges of the parent repository. Second, they used that execution to poison the build cache between forks. Third, they extracted authentication tokens directly from the CI/CD runner's memory while it processed the malicious build.
In the first 6 minutes, the attackers published 84 malicious versions across 42 different @tanstack packages. Within 48 hours, that count had grown to 172 packages and 403 malicious versions across both npm and PyPI.
7 days later, a separate worm campaign called Megalodon injected malicious GitHub Actions workflow code into 5,500 public repositories during a 6-hour window. The injected workflow stole cloud credentials, SSH keys, API tokens, and OIDC authentication tokens from every pipeline run that followed. Anyone who forked one of those 5,500 repositories during that window still has the backdoor in their copy.
The next day, the same threat group behind Mini Shai-Hulud published 3 malicious versions of Microsoft's official Azure Durable Functions Python SDK to PyPI. That SDK is downloaded around 400,000 times a month by legitimate users. The malicious versions contained a Linux file-wiper paired with a credential stealer that targeted AWS, Azure, GCP, Kubernetes, and roughly 90 developer tool configurations. The malicious versions were live on PyPI for 35 minutes before Microsoft pulled them.
On that same day, the same threat group hit a separate target. They compromised @antv, a family of data-visualization libraries used widely in JavaScript projects. In a 22-minute automated burst, they published 300 malicious versions across 323 different packages. Those packages collectively receive 16 million downloads a week.
All of that happened in a single week.
The broader pattern matches the one-week sample. Sonatype, a software supply chain security firm, counted 454,600 newly identified malicious open-source packages in 2025. That was up 75% over 2024. JFrog, another supply chain security vendor, tracked a 451% increase in malicious npm packages specifically. The overall attack rate against the open-source supply chain ran at 13 attacks per month in early 2024, climbed to 28 per month by April 2025, and reached 41 per month by October 2025.
The upstream packages most teams depend on are no longer mostly trustworthy. A growing share of them are now actively malicious.
Signed packages can be faked
The Mini Shai-Hulud campaign also produced something the supply chain security community had not seen before. Malicious npm packages that carried valid SLSA provenance.
SLSA, short for Supply-chain Levels for Software Artifacts, is the cryptographic signing framework the industry adopted to prove that a package is what its maintainer intended to ship. The signature is generated by the CI/CD pipeline that builds the package and is supposed to act as a trust anchor for everything downstream.
That signature can now be forged. Not by breaking the cryptography itself. By compromising the CI/CD pipeline that produces the signature in the first place.
If your supply chain security strategy rests on "the signed package is what the maintainer meant to ship," that assumption no longer holds in 2026. The signature now proves only that the pipeline produced the package. If the pipeline is compromised, the signature certifies the compromise.
This is the assumption almost no one is rewriting in their threat model yet. It invalidates a decade of "you can trust signed packages" guidance.
Patching faster makes it worse
A security operations team responding to AI-discovered vulnerabilities by tightening its patch frequency is doing two things at the same time. It is closing exposure windows on known vulnerabilities. It is also ingesting more upstream package versions, more often, with less time to vet each patch or update before installing it.
In 2023, those two effects pointed the same direction. Closing a vulnerability window was net positive. Pulling more recent package versions was net positive. There was no meaningful supply chain integrity risk in the act of patching itself.
In 2026, those two effects point opposite directions. Every patch pull is now a chance to ingest a compromised package. The same dependency-update mechanism that closes a vulnerability is the mechanism the attackers are using to deliver malware that destroys data and steals credentials.
To make matters more complex and challenging, the attackers have AI on their side too.
On March 11, 2026, a separate threat actor opened over 500 malicious pull requests across 6 different GitHub accounts. The payloads began as crude bash scripts. With no human direction, the scripts evolved into code that recognized the target repository's tech stack and rewrote itself to blend in. A security team patching faster in 2026 is also pulling more code from an upstream that an attacker's AI has tailored specifically to the team's own environment.
Patch faster used to be a safe default. It is now one of two competing pressures. The other pressure is to avoid ingesting compromised packages from a hostile upstream. The security frameworks most teams operate against still treat patch velocity as the only pressure that matters.
Where this leaves you
The right answer is more complicated than "patch faster." It does not fit on a board slide about patch SLAs.
The security framework your team is operating against is calibrated for a world that no longer exists.
Patch faster was right for 20 years. It is not right now.
In May 2026, that playbook stopped working. Most security teams have not noticed yet.
