Every keynote this spring told us the same thing: AI compressed the gap between disclosure and weaponization, so the answer is to patch faster. Fine. But I went back through what actually got exploited over the last several weeks, and most of the worst of it would not have cared how fast you patched. The bugs were not clever. They were trust assumptions and missing integrity checks we have had named CWE categories for since before half of you started writing code. Here is the mechanism on four of them, with the detection you can run today.
The trust model is the attack surface (AUR, no CVE)
Around June 11, somebody adopted a pile of orphaned packages in the Arch User Repository, edited the build recipes, and turned them into credential stealers. Over 400 confirmed, more on the community lists as cleanup dragged on. There was no zero-day and no breach of Arch's own infrastructure. The official repos were never touched.
The mechanism is the insulting part. The attacker edited PKGBUILD and .install files to invoke npm during the build, pull a malicious package (atomic-lockfile), and drop a stripped Rust binary that harvests SSH keys, tokens, browser data, cloud creds, and messaging sessions. A second wave swapped npm for bun to dodge signatures keyed on the first. What got exploited was the AUR's trust model: it trusts a package's name and history over who maintains it right now, and adopting an abandoned package is a sanctioned process. Nobody broke in. They walked through a door the system holds open by design.
Triage if you run Arch:
# Foreign (AUR) packages by install date -- anything touched on/after June 11 is suspect
pacman -Qqm | while read pkg; do
pacman -Qi "$pkg" | grep -E "^(Name|Install Date)" | paste - -
done | sort -k4
# Diff the PKGBUILD of anything recent. Treat npm/pip/cargo/bun calls with no
# relationship to the software's function as hostile:
grep -nE "npm|pip|cargo|bun" PKGBUILD *.install 2>/dev/null
# The optional eBPF rootkit pins BPF maps under these names. If they exist,
# stop trusting the host's own tooling:
ls -la /sys/fs/bpf/hidden_* 2>/dev/null
One nuance the early coverage got wrong: the eBPF rootkit is optional, root-only (needs CAP_BPF), and does not escalate privilege. It just hides the stealer after the fact. But that changes your cleanup math. If the payload ran as root, pacman -R does not clean the box -- a package manager only deletes files it knows about, and a rootkit's whole job is to not be one of them. Rebuild from clean media or do not trust the host.
CVE-2026-0257: a firewall that trusts any cookie it can decrypt (PAN-OS)
This is a security appliance failing at the one thing it exists to do. The GlobalProtect portal issues an encrypted "authentication override" cookie so users do not re-auth constantly. When the 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.
It gets worse if the same certificate is reused for the box's HTTPS service, which is a common config, not an exotic one. An attacker connects over HTTPS, pulls the public key, and forges a cookie the firewall accepts as gospel. Rapid7 saw exploitation start May 17. Palo Alto quietly bumped the CVSS from 4.7 to 7.8 on May 29, the same day CISA added it to the KEV.
You are exposed only if both are true: authentication override cookies are enabled on the portal or gateway, and the cookie-encryption certificate is shared with another service. Check Network > GlobalProtect > Portals/Gateways > Agent > Authentication for the override setting. Mitigation is to disable authentication override or generate a certificate used only for cookie encryption and shared with nothing else. Prisma Access was also in the affected list; Panorama and Cloud NGFW were not.
Hunt your GlobalProtect logs for the PoC's tells:
# Forged-cookie sessions in the public PoC showed:
# - cookie auth to the local admin account from low-cost hosting IPs (Vultr, etc.)
# - source user with an EMPTY domain field
# - endpoint_os_version: "Microsoft Windows 10 Pro 64-bit"
# Grep gateway-auth login events and validate any "Cookie" auth to local admin:
grep -E "gateway-auth.*login.*Cookie" /path/to/globalprotect.log
CVE-2026-20182: a control plane whose auth step doesn't authenticate (Cisco SD-WAN)
This one is a months-long pattern, and Cisco is wearing it. On April 20, CISA KEV-listed three Catalyst SD-WAN Manager flaws that chain into unauthenticated access: CVE-2026-20122 (incorrect use of privileged APIs), CVE-2026-20128 (storing passwords in a recoverable format), and CVE-2026-20133 (sensitive information exposure). Then on May 14 came the one that should have been the headline: CVE-2026-20182, CVSS 10.0, an authentication bypass in the SD-WAN control plane where the peering-authentication step simply does not authenticate (CWE-287). A sophisticated actor Cisco tracks as UAT-8616 hit it as a zero-day. CISA issued Emergency Directive 26-03 over it, and once PoC code circulated, researchers counted roughly ten additional clusters piling on. June added two more, including a path traversal (CVE-2026-20262) letting an authenticated attacker overwrite any file on the box.
This is the controller that pushes config across your entire fabric -- the single most privileged box in the network -- and over a few months it shipped recoverable password storage, an info leak, a path traversal, and a control-plane auth mechanism that does not authenticate. After exploiting 20182, UAT-8616 injected an attacker key into the vmanage-admin account, then logged in over NETCONF (SSH on TCP 830) and started issuing commands.
# Hunt for the attacker key injection on SD-WAN control components:
grep "Accepted publickey for vmanage-admin" /var/log/auth.log
# Then manually validate every control-connection peering event -- especially
# vmanage peering types -- from unrecognized IPs or at unexpected times.
CVE-2026-35273: the one that was actually hard (PeopleSoft)
Credit where due: this was a genuine zero-day. ShinyHunters (Mandiant tracks them as UNC6240) spent late May and early June tearing through Oracle PeopleSoft via CVE-2026-35273, an unauthenticated RCE in the Environment Management component of PeopleTools 8.61 and 8.62, rated 9.8. Mandiant dates exploitation to May 27 through June 9. Oracle's out-of-band advisory did not land until June 10 -- the whole campaign ran before there was anything to patch. Mandiant notified 100+ orgs; 68% were higher ed. CISA KEV-listed it June 12.
Post-exploit, they dropped MeshCentral agents masquerading as Azure services (C2 at azurenetfiles[.]net), ran a *_fanout.sh lateral-movement/defacement script, and exfiltrated with zstd.
# Breach marker dropped into PeopleSoft web/app directories:
find / -name "README-IF-YOU-SEE-THIS-YOUVE-BEEN-HACKED.TXT" 2>/dev/null
# Compensating controls (Oracle/Mandiant guidance):
# - Disable the Environment Management Hub (EMHub) service, or remove PSEMHUB
# - Block external access to /PSEMHUB/* and /PSIGW/HttpListeningConnector
# - Watch outbound SMB (TCP 445) from PeopleSoft hosts to external destinations
The pattern: you can't patch a broken assumption
Now the macro picture, because it is the actual argument. Per Verizon's 2026 DBIR, the median time to fix a known-exploited vulnerability went up year over year, 32 days to 43, and the share fully patched fell from 38% to 26%. Rapid7's 2026 report logged a 105% jump in confirmed exploitation of high- and critical-severity flaws (71 cases to 146), and the disclosure-to-weaponization window that CSA and the Zero Day Clock now measure in hours used to take weeks. Offense compresses, remediation expands, and yes, AI compressed the discovery-and-weaponization side. That part is real.
But look at what it bought the attackers in these four. None of them 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 can decrypt, a control plane whose auth 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.
"Patch faster" is not wrong so much as beside the point. These were design failures we agreed to ship, and no amount of velocity downstream fixes a broken assumption upstream. The window did collapse. The bugs that walked through it did not need it to.
What is the worst trust-by-default you have found still shipping in a box you were told to trust? I want the examples.
Originally published at blog.vertexops.org.