Today Microsoft released 198 security patches. SAP patched 21 vulnerabilities. A Linux kernel proof-of-concept went public. Cisco issued a critical advisory. CISA added three entries to the Known Exploited Vulnerabilities catalogue.
And this is a normal Tuesday in June.
The security industry has developed, over the past decade, an extraordinary capacity to normalise the impossible. A single vendor patching 198 vulnerabilities in one day is described in the same tone as a weather forecast. Security teams are expected to triage 198 CVEs, identify the six zero-days among them, assess their applicability to their environment, escalate for emergency action the ones that are wormable or actively exploited, and do all of this between now and when attackers who have been waiting for public disclosure start scanning.
The security community does not discuss whether this is a reasonable expectation. It has simply accepted it as the rhythm of the industry.
The Asymmetry
There is a fundamental asymmetry in how Patch Tuesday works. Microsoft’s patch engineering team — an organisation of hundreds of engineers — produces 198 fixes. Each fix is a response to a disclosed vulnerability, and each vulnerability required months of work from the researcher who found it. The knowledge of each vulnerability is concentrated at Microsoft and the researcher before public release.
When the patches drop, that knowledge becomes everyone’s problem simultaneously. Every enterprise in the world — from a three-person IT team at a regional law firm to a 500-person security operations team at a global bank — receives the same 198-vulnerability disclosure at the same time and is expected to process it.
The resources available to the security team at the regional law firm are not comparable to what was required to produce those patches. The timeline — “patch critical and actively exploited vulnerabilities immediately” — does not account for the difference in capacity.
The result is predictable: triage is incomplete, prioritisation is imprecise, and the patches that most need to be applied quickly are often the patches that take the longest to reach production — because the highest-urgency patches are the ones that require the most testing and carry the most change risk.
The CVSS Problem
CVSS scores help, and they don’t help enough. CVE-2026-47291 (HTTP.sys, wormable, CVSS 9.8) and CVE-2026-50507 (BitLocker bypass, physical access required, CVSS 6.8) both appear in the same patch list. The CVSS difference signals that one is more critical than the other — but the CVSS score does not tell you whether you have IIS servers facing the internet, or whether your threat model includes targeted physical device theft.
Effective prioritisation of 198 CVEs requires environmental context that CVSS does not encode. It requires knowing which affected products you run, which are internet-facing, which are running what configuration, which are covered by compensating controls. Producing that context for 198 CVEs on the day they are disclosed is beyond the capacity of most security teams.
The vendors that sell CVSS-enriched patch prioritisation platforms are selling a real service. But the existence of a market for “help us prioritise these 198 patches” is itself evidence that the underlying process is broken.
What Normal Should Look Like
There is no obvious solution to this. Reducing patch volume would require reducing vulnerability discovery — not a realistic goal. Moving to continuous deployment would help if every enterprise ran cloud-native infrastructure where patches could be applied without change management — most do not. Increasing patch team capacity does not scale proportionally with patch volume.
What would help is an honest industry acknowledgement that the current Patch Tuesday model creates a predictable gap between vendor disclosure and enterprise remediation — and that threat actors who understand this gap exploit it deliberately. Today’s six zero-days were publicly known before the patch was available. Some of them were known to attackers before they were known to Microsoft. The public disclosure in the Patch Tuesday bulletin is not the beginning of the window — it is, in some cases, the end of it.
The security community would be better served by discussing this structural problem than by publishing another list of which 198 CVEs to patch first.
Start with CVE-2026-47291. Then CVE-2026-45657. Then CVE-2026-47288. Then come back and read this editorial again.
Share this article