Four Failures, One Excuse: "Patch Faster" Was Never the Answer

Here is the number I cannot stop thinking about. According to Verizon's 2026 DBIR, the median time for an organization to fix a known-exploited vulnerability went up year over year, from 32 days to 43. The share of those vulnerabilities that got fully patched fell from 38% to 26%. Defenders did not get faster this year. They measurably got slower. Meanwhile the exploitation side ran the other direction: Rapid7's 2026 threat report logged a 105% jump in confirmed exploitation of high- and critical-severity flaws, from 71 documented cases to 146. And the disclosure-to-weaponization gap that the Cloud Security Alliance and the Zero Day Clock now describe in hours used to be measured in weeks. Offense compresses. Remediation expands. The clock is running backward.

The standard read on this is that AI broke vulnerability management. That is half right, and the half it gets wrong is the half that matters. AI did compress the discovery-and-weaponization side of the window -- that part is real and well documented. What it did not do is make the bugs sophisticated. I went back through what actually got exploited this spring, and the worst of it was not clever. It was trust assumptions and missing integrity checks that we have known how to fix for twenty years. The "patch faster" sermon misdiagnoses the problem, because speed was never the thing that failed.

Start with the one that did not even get a CVE. Around June 11, somebody adopted a pile of orphaned packages in the Arch User Repository, rewrote their build scripts, and turned them into credential stealers. Over 400 packages confirmed, with community lists climbing well past that as the cleanup dragged on. The mechanism is almost insulting in its simplicity: the attacker edited the PKGBUILD and .install files to invoke npm during the build, pull a malicious package called atomic-lockfile, and drop a stripped Rust binary that harvests SSH keys, tokens, browser data, cloud credentials, and messaging sessions. Sonatype tracked it as Sonatype-2026-003775 and rated it 8.7. There was no zero-day. There was no breach of Arch's own infrastructure. The official repositories were never touched.

What got exploited was the trust model. The AUR trusts a package's name and history over the question of who is maintaining it right now, and adopting an abandoned package is a normal, sanctioned process. The attacker did not break in. They walked in through the front door the system holds open by design. There is an eBPF rootkit in the payload, and the early coverage oversold it badly, so let me be precise: it is optional, it only loads when the binary already has root and CAP_BPF, and it does not escalate privilege. All it does is hide the stealer after the fact. That nuance matters, because it changes your cleanup math. If the payload ran as root, removing the package does not clean the machine -- a package manager can only delete files it knows about, and a rootkit's entire job is to make sure it is not one of them. Rebuild from clean media or do not trust the host.

Then there is PAN-OS, where a security appliance failed at the one thing a security appliance is supposed to do. CVE-2026-0257 is an authentication bypass in the GlobalProtect portal and gateway. The device issues an encrypted "authentication override" cookie so users do not have to re-auth constantly. The problem is what happens when that cookie comes back: PAN-OS decrypts it with its private key and then trusts the contents without verifying a signature. The CWE is 565, reliance on cookies without integrity checking, and if that sounds like a flaw you would catch in a first-year security review, that is because it is.

It gets worse on contact. If the same certificate is reused for the box's HTTPS service -- a common configuration, not an exotic one -- an attacker just connects over HTTPS, grabs the public key, and forges a cookie the firewall will accept as gospel. Rapid7 watched exploitation start May 17. Palo Alto quietly raised the CVSS from 4.7 to 7.8 on May 29, the same day CISA added it to the KEV catalog, which is the polite corporate way of admitting the original score did not survive contact with reality. The fix list includes Prisma Access; Panorama and Cloud NGFW were not affected, so this is not all of PAN-OS. But the perimeter device a lot of shops bought specifically to enforce authentication was, for a window, forging its own.

The third one is not a single bug. It is a months-long pattern, and Cisco is the one wearing it. Since the late winter, a string of Catalyst SD-WAN flaws has landed in the KEV catalog, and reading them in order is its own indictment. On April 20, CISA added three that chain together into unauthenticated access: CVE-2026-20122 (incorrect use of privileged APIs), CVE-2026-20128 (storing passwords in a recoverable format), and CVE-2026-20133 (exposure of sensitive information). Then on May 14 came the one that should have been the headline -- CVE-2026-20182, a CVSS 10.0 authentication bypass in the SD-WAN control plane, where the peering-authentication step simply does not authenticate. A sophisticated actor Cisco tracks as UAT-8616 hit it as a zero-day; CISA considered it serious enough to issue Emergency Directive 26-03, and once proof-of-concept code circulated, researchers counted roughly ten additional threat clusters piling on. June added two more Manager and control-plane flaws on top, including a path traversal (CVE-2026-20262) that lets an authenticated attacker create or overwrite any file on the box.

Stack that up. This is the controller that pushes configuration across your entire SD-WAN fabric, the single most privileged piece of the network, and over a few months it shipped recoverable password storage, a sensitive-information leak, a path traversal, and a control-plane authentication mechanism that does not authenticate. That is not bad luck. It is a class of trust failure that kept clearing QA because nobody upstream treated the fabric manager as the crown jewel it obviously is.

And then, for contrast, the one that was actually hard. ShinyHunters spent late May and early June tearing through Oracle PeopleSoft using CVE-2026-35273, an unauthenticated remote code execution flaw in the Environment Management component of PeopleTools 8.61 and 8.62, rated 9.8. This was a genuine zero-day. Mandiant dates the exploitation to May 27 through June 9, which is the part that should make you sit up: Oracle's out-of-band advisory did not land until June 10. The whole campaign ran before there was anything to patch. Mandiant attributes it to the cluster it tracks as UNC6240, notified more than 100 organizations, and found that 68% of them were in higher education. CISA added it to the KEV on June 12. The University of Nottingham has confirmed a cybersecurity incident affecting its systems, which public reporting ties to this campaign.

I put PeopleSoft last on purpose, because it is the closest thing here to a fair fight: a real zero-day in a complex enterprise stack, exploited before disclosure, by a crew that knew PeopleSoft internals cold. And here is the uncomfortable part. The damage it did is not obviously worse than what a forged cookie or an adopted package did. The boring trust failures kept pace with the genuine zero-day. That is the whole argument. We are pouring budget into outrunning the hard, fast, AI-accelerated end of the threat curve and getting quietly robbed at the other end by mechanisms a competent reviewer would have flagged in an afternoon.

So when the next briefing tells you the answer to the collapsing exploit window is to buy something that patches faster, ask the obvious question. Patch speed fails on both ends of this set. None of the four was a speed problem at root -- you cannot patch your way out of a package trusted because the system likes its name, a firewall that trusts any cookie it manages to decrypt, a control plane whose authentication step does not authenticate, or an ERP endpoint left facing the internet. And in two of them, Cisco's 10.0 and the PeopleSoft RCE, the attackers were already inside before a patch existed at all. You cannot out-patch a clock that started before the vendor knew. Those are not velocity failures. They are design failures we agreed to ship, and no amount of speed downstream fixes a broken assumption upstream. The window did collapse. But the bugs that walked through it did not need it to.