May 2026 has been a month of critical vulnerabilities. Critically critical vulnerabilities. Multiple simultaneous CVSS 10.0 vulnerabilities, several CVSS 9.8 vulnerabilities with confirmed active exploitation, and a CVSS 9.3 (CVSSv4) network appliance vulnerability under mass exploitation despite a patch being available for more than two months.
The security industry’s instinct when confronted with this density is to describe each vulnerability as requiring immediate emergency response. That instinct is correct for the highest-severity items. It creates a problem when applied uniformly to the full list.
Security teams have finite capacity. When the list of “critical emergency” items runs to ten simultaneous vulnerabilities across different infrastructure classes, the term stops functioning as a triage signal. Engineers cannot simultaneously run emergency response procedures against domain controllers, network appliances, AMD server firmware, Linux kernels, and developer workstations. Something has to be sequenced. And sequencing decisions — deciding what comes first — are prioritisation decisions that the “critical” label was supposed to short-circuit but now cannot.
The Scoring Drift Problem
CVSS scoring has experienced documented drift toward higher scores over the past decade. A vulnerability that would have scored 7.5 in 2015 often scores 9.0 in 2026, not because the vulnerability class has changed but because scoring conventions have evolved toward higher base scores for the same vulnerability characteristics.
The effect is that the CVSS threshold for “critical” (9.0+) now captures a larger fraction of all CVEs than it did when the threshold was set. Critical was designed to be rare. It is no longer rare. When 15–20 per cent of vulnerabilities scored in a given month exceed the critical threshold, critical has lost its triage value as a category.
NVD data confirms this pattern: the fraction of CVEs receiving a CVSS 9.0+ base score has risen steadily since 2018. The scoring methodology has been updated (CVSS 4.0 was published in 2023) but the inflation trend preceded and continued through the update.
What Better Prioritisation Looks Like
The industry has partially recognised this problem. EPSS (Exploit Prediction Scoring System) attempts to score the probability that a vulnerability will be exploited in the next 30 days, providing a probability-based complement to severity-based CVSS. CISA’s KEV catalogue provides a ground-truth signal: these specific vulnerabilities are confirmed exploited today.
The practitioner prioritisation hierarchy that emerges from combining these signals:
- KEV + your technology stack: If CISA confirms a vulnerability is being exploited in the wild and the affected product is in your environment, response is immediate regardless of CVSS score
- High CVSS + your technology stack + public PoC: High urgency — the exploitation gap from patch to PoC to mass exploitation is measured in days, not weeks
- High CVSS + your technology stack + no PoC: Standard priority — patch within your high-severity SLA
- High CVSS + not in your technology stack: Document, revisit when inventory changes, do not treat as immediate
This hierarchy requires knowing your technology stack well enough to apply it. The organisations that struggled most with Q2 2026’s vulnerability density were often the same ones with incomplete asset inventory — they could not quickly determine whether they ran Oracle WebLogic, or how many AMD Zen 2 servers they had, or which branch offices ran UniFi OS.
The CVSS Score Is Not the Risk
CVSS measures the intrinsic characteristics of a vulnerability: attack vector, complexity, required privileges, user interaction, impact. It does not measure whether you have the affected product, whether it is exposed to the relevant attack vector in your environment, whether exploitation is active, or whether exploitation would achieve something of value to an attacker in your specific context.
CVE-2026-41089 (Netlogon, CVSS 9.8, active exploitation) is a higher-priority patch than a CVSS 10.0 vulnerability in a product you do not use. Both scores are accurate descriptions of the vulnerabilities’ intrinsic characteristics. Only one represents an immediate risk to your environment.
The operational lesson from Q2 2026 is not that patching is harder when there are more critical vulnerabilities — that is obvious. The lesson is that security programmes that have not built asset-aware prioritisation processes are at a systematic disadvantage when vulnerability density is high. The investment in knowing what is running in your environment pays dividends every time vulnerability density spikes.
It will spike again. Q3 2026’s conference season — DEF CON, Black Hat, numerous academic venues — will produce another cluster of high-severity disclosures. Build the prioritisation capability before it arrives.
Share this article