23 KEV Additions in 30 Days: June Was the Fastest Exploitation Month on Record — Can Your Patch Cycle Keep Up?

June 2026 is in the books, and it set two records at once. Microsoft shipped its largest Patch Tuesday ever — 206 vulnerabilities, 39 rated Critical, three zero-days — and CISA closed out the most aggressive Known Exploited Vulnerabilities cycle on record, adding 23 entries to the KEV catalog in 30 days. If your patching cadence still assumes a monthly rhythm with the occasional out-of-band scramble, June was the month that assumption formally expired.

What actually happened in June

The KEV catalog is CISA’s list of vulnerabilities with confirmed, in-the-wild exploitation. It is deliberately conservative: a bug only lands there when someone is actively using it against real organisations. Twenty-three additions in a single month means attackers weaponised roughly five vulnerabilities per week — and that’s just the confirmed subset.

Several of June’s entries will feel familiar if you run Windows fleets. CISA confirmed that ransomware gangs are now exploiting BlueHammer (CVE-2026-33825), the local privilege escalation leaked with proof-of-concept code back in April. The two Microsoft Defender elevation-of-privilege flaws (CVE-2026-41091 and CVE-2026-45498) also carried federal remediation deadlines into June. The pattern across all three: local privilege escalation on the Windows endpoint, moving from disclosure to criminal exploitation in weeks.

Why exploitation velocity keeps climbing

This isn’t a one-off spike. Microsoft’s own Security Response Center has acknowledged that AI tooling is changing the scale and speed of vulnerability discovery — for researchers and attackers alike. More bugs are being found, proof-of-concept code circulates faster, and the gap between “patch available” and “exploit in a ransomware playbook” has compressed from months to days.

You cannot out-patch that curve by working harder within the same process. The teams keeping up are the ones that changed the process.

Treat KEV as your priority queue, not a federal formality

KEV deadlines formally bind US federal civilian agencies. But the catalog is the closest thing your team has to a free, curated “attackers are using this right now” feed — and it’s a far better prioritisation signal than raw CVSS scores. A 7.8 local privilege escalation that’s in KEV deserves to jump the queue ahead of a 9.1 that nobody is exploiting.

A KEV-driven patching workflow in six steps

1. Watch the feed daily. Subscribe to the KEV catalog update notifications, or pull the JSON feed into whatever your team already watches — a Teams channel works fine. This takes minutes to set up.
2. Map KEV entries to your estate automatically. A KEV addition is only actionable if you can answer “how many of our devices are affected?” within the hour. Your endpoint management or vulnerability management platform should give you that query saved and ready.
3. Set an internal KEV SLA. Federal agencies typically get two to three weeks. Pick your own numbers — for example, 7 days for KEV entries on user endpoints, 48 hours if the entry is under ransomware exploitation — and get management sign-off so the SLA carries weight when it disrupts other work.
4. Build an expedited deployment ring. Your normal ring structure (pilot, broad, critical-last) is built for stability. Keep it — but define a compressed variant for KEV items: pilot for 24 hours, then broad. Practise it before you need it.
5. Document compensating controls for the ones you can’t patch fast. Some KEV entries land on systems you cannot reboot this week. For those, write down what you did instead — attack surface reduction rules, disabled services, network isolation — and a date you’ll revisit.
6. Verify, don’t assume. “Deployed” and “installed” are different states. Close each KEV item against actual compliance data, not the deployment job status.

The local admin multiplier, again

Look back at what June’s KEV additions had in common: most of the Windows entries were elevation-of-privilege bugs. Every one of them matters far less on an endpoint where the user is a standard user and far more where the user is a local admin — because on an admin endpoint, the attacker often doesn’t even need the exploit. If your KEV response time can’t get faster, reducing standing privilege is the other lever: it lowers the value of every LPE bug you haven’t patched yet.

What to do now

1. Subscribe your team to KEV catalog updates today — it’s a ten-minute job.
2. Run the June KEV list against your estate and confirm nothing is still exposed, starting with BlueHammer (CVE-2026-33825) and the two Defender EoP flaws.
3. Draft a KEV SLA (7 days endpoints / 48 hours ransomware-exploited is a reasonable starting point) and get it agreed before July’s Patch Tuesday lands on the 14th.
4. Define and test your expedited deployment ring on a low-stakes update this month.
5. Pull your local admin numbers. If KEV velocity keeps rising — and every signal says it will — standing privilege reduction is the mitigation that works on bugs nobody has disclosed yet.