This week, a reasonably sized enterprise security team was expected to:
- Triage 198 Microsoft CVEs from the Patch Tuesday disclosure
- Identify and act on a separate CVSS 10.0 Ivanti advisory disclosed the same day
- Process three CISA KEV additions (Chrome, Cisco, Arista) also released on Tuesday
- Maintain awareness of the SAP CVSS 9.9 advisory from Monday
- Continue tracking the Gentlemen ransomware worm now confirmed across 66 countries
- Manage the Linux CVE-2026-23111 PoC released the same week
And then deploy emergency patches across Windows Server infrastructure, domain controllers, and workstations faster than normal change management allows.
A mid-sized enterprise security operations team is five to fifteen people. Some of them are on call, some are on leave. They also have a SIEM generating alerts, a ticket queue from end users, ongoing vendor assessments, and whatever security incident happened last week that is still being closed out.
The volume of what happened this week is not unusual. It is Tuesday in June.
The Model We Are Using Was Designed for a Different Problem
The modern enterprise vulnerability management model was designed in the early 2000s, when a major vendor releasing ten patches in a month was significant news. The model assumed:
- A manageable number of vulnerabilities per month
- Sufficient time between disclosure and exploitation for organisations to assess and remediate
- A clear distinction between “critical” and “non-critical” that could be used for triage
None of these assumptions remain true. The June 2026 Patch Tuesday alone disclosed 198 vulnerabilities, with six publicly known before the patch. The time between disclosure and weaponisation for critical vulnerabilities has compressed from weeks to hours. CVSS alone no longer separates actionable urgent from actionable routine — this week’s six zero-days range from 6.8 to 9.8, and the CVSS difference correlates to different risk dimensions (physical-access physical access vs. wormable remote) rather than simply ordering from worst to less bad.
The industry response to this problem has been to add more tools. CVSS enrichment platforms. Threat intelligence feeds that score CVEs by exploitation likelihood. Vendor risk scores. EPSS (Exploit Prediction Scoring System). All of these are genuine improvements. None of them reduce the volume to something a five-person team can process.
The KEV Is the Best Thing That Has Happened to Vulnerability Management
CISA’s Known Exploited Vulnerabilities catalogue is the most practical contribution to enterprise vulnerability management in the past decade. It answers the only question that actually matters for prioritisation: is this being exploited right now against real targets?
The KEV currently contains roughly 1,200 entries accumulated since 2021. This week added four. The signal-to-noise ratio is extremely high — if something is on the KEV, it is being used by attackers against real systems. Organisations that track the KEV and remediate KEV entries within 30 days are not operating best-in-class vulnerability management, but they are operating practically viable vulnerability management with a defensible prioritisation framework.
The limitation of the KEV is that it is reactive — it documents confirmed exploitation, not predicted exploitation. The June 2026 HTTP.sys flaw (CVE-2026-47291) is not on the KEV yet (at time of writing), but it is a wormable CVSS 9.8 flaw that will certainly be exploited. A KEV-only prioritisation strategy would miss it until exploitation is confirmed.
The honest answer is that there is no prioritisation framework that is both comprehensive and simple enough for resource-constrained security teams to apply across 198 CVEs in 24 hours. The best available approach combines KEV tracking with the CVSS 9.0+ filter and wormable/actively-exploited flags from the vendor advisory.
What Needs to Change
The industry does not discuss the underlying economics of this problem because the economics are uncomfortable. Vendors ship more features, which introduces more vulnerabilities. The security tools market benefits from vulnerability volume because it creates demand for prioritisation, scanning, and management products. Security teams receive budget based on perceived risk, and high CVE volume creates perceived risk.
The structural incentive in the security industry is not to solve the volume problem.
What would actually help:
Mandatory pre-release security testing for high-risk code paths: The three CVSS 9.8 vulnerabilities in the June Patch Tuesday are all in fundamental Windows components — HTTP.sys, the kernel, DHCP Client. These are not obscure features. They are components that process untrusted input at scale. Organisations writing software with these characteristics would benefit from regulatory requirements or contractual mandates for adversarial pre-release testing. Vendors resist this; buyers do not currently have sufficient leverage to require it.
Coordinated vendor disclosure alignment: Six vendors disclosed critical vulnerabilities within 48 hours this week. Each requires independent triage, independent testing, and independent deployment. A coordinated disclosure window — where all vendors in a given sector align critical disclosure to the same day (Microsoft, SAP, Citrix, Ivanti, Palo Alto) — would not reduce volume but would allow teams to consolidate their emergency response capacity rather than distributing it across the month.
AI-assisted triage that earns practitioner trust: AI tooling exists for CVE triage. It is not yet trusted by practitioners to make remediation priority decisions. If AI triage reaches practitioner trust levels, it could meaningfully help with the volume problem. It is not there yet.
This week’s volume was manageable, barely, for well-resourced organisations. For the majority of enterprises with security teams of fewer than ten people, it was not. The breach statistics for the next quarter will measure the gap.
Share this article