Most of this week's exploited flaws were ones CVSS said could wait

Line up every flaw we covered this week by its CVSS score and the order comes out almost exactly upside down. The two 9.8s that led the security news, a Linux kernel TCP flaw and a jackson-databind fix bypass, had no reported attacks when we wrote them up. The bugs attackers were actually using sat at the bottom: an ESXi logging flaw scored 2.7, a 4.3 link in an Ivanti chain, a WordPress updater race its own maintainers rate Low, and a Drupal Commerce bypass with no CVSS score at all.

Of the five flaws we covered this week that were exploited or under active probing, four scored low, were rated Low by their own vendor, or carried no score. The fifth was a 9.8 that had been fixed for two years. A patch queue that starts at the top of the CVSS column would have handled this week in the wrong order, and it would not have been a careless queue. It would have been doing exactly what most patch policies tell it to do.

The common rule, and what this week did to it

The standard triage rule is simple: patch critical and high first, batch the mediums into the monthly cycle, and let the lows wait. Plenty of automation encodes it literally, as a "CVSS 7.0 or above" gate on what gets an emergency window. The rule is defensible because the score is usually honest about the bug. It measures what one flaw gives one attacker against one target.

That is also the limit. Attackers this week were not buying bugs. They were buying position, and CVSS has no column for position.

The chart puts the six scored flaws in severity order: Linux kernel 9.8, jackson-databind 9.8, Synology DSM 9.8, WordPress 8.1 (Wordfence's figure; WordPress itself says Low), the Ivanti link at 4.3, and ESXi at 2.7. The bottom two are both in CISA's Known Exploited Vulnerabilities (KEV) catalog, listed on October 28 and October 30. The top two are not. Drupal Commerce CVE-2026-118539 does not appear because there is no score to plot, even though Drupal's advisory says it is being exploited in the wild.

Three things a severity score cannot see

Each low scorer this week was dangerous for a reason that sits outside the bug itself. Taken together they describe three blind spots, and we think they will keep recurring.

The chain. Ivanti Connect Secure CVE-2026-118527 scores 4.3 because on its own it only lets a logged-in user write a file to a predictable place. Next to an authentication bypass and a root escalation, it is the bridge between them. CVSS scores each CVE separately, so no score anywhere describes the chain. We saw the same shape ten days earlier with Plex2Shell, four flaws scored 5.3 to 8.6 that combine into one unauthenticated shell. Twice this month, the KEV catalog listed a chain whose individual scores would not have triggered an emergency window.

The fleet. The WordPress updater race is genuinely hard to win against any one site: the window lasts seconds during a core update. That is why WordPress rates it Low. But attackers are not aiming at one site. Across millions of installs pulling the same release within hours, someone is always mid-update, and Wordfence saw its two busiest sources keep hammering the same handful of sites for about 14.5 hours, waiting for one to start updating. The score describes one host. The attack is run against the internet.

The evidence. ESXi CVE-2026-41709 scores 2.7 because it requires admin rights and grants nothing new. What it does give is unrecorded actions on a hypervisor, which is worth more to an intruder who already holds access than another way in. Severity scoring has no input for "this hides the other intrusion."

The low scorers were also the quiet ones

This is the part that worries us most, and the reason this is more than a scoring complaint. The bugs a score-gated queue pushes to the back are, this week, the same bugs least likely to set off an alarm while they wait.

The ESXi flaw suppresses the log record where it is created, so forwarding logs to a remote collector does not help; an event never written never leaves the host. The Ivanti campaign, as Volexity described it, dropped no malware and edited the appliance's logs afterwards. The Drupal Commerce bypass is a business-logic flaw whose damage lands in order records that look like ordinary sales, with no new file or odd process to catch. Drupal's only guidance beyond updating is to audit orders for inconsistencies. Even the WordPress race runs code in a staged copy of the installer that the live site never loads, so a security plugin that loads with WordPress does not see the request.

Put the two effects together and the cost compounds. A low score delays the patch, and the bug's nature hides use during the delay. A 9.8 at least gets attention: a team patching it knows to look. A 2.7 logging bypass gets neither the patch nor the look. Low severity and low visibility are separate properties, but this week they arrived together on the same bugs, and a triage process that handles one without the other leaves the widest gap exactly where an intruder would want it.

We are not exempt. Our July write-up of VMware's advisory led with the 9.8 vCenter bugs and filed the logging weakness as a footnote. Our own automated triage first logged CVE-2026-41709 on July 30 and still had it in its watch queue when CISA listed it on October 28. Across the last seven days our desks triaged 6,327 vulnerabilities and, by our tracking, flagged around 77 with signs of exploitation; 6,244 of the 6,327 are still in the watch queue. A queue that size has to be sorted by something. Our point is that CVSS alone is the wrong first key.

The one 9.8 that was used had been fixed since 2024

The exception proves the same point from the other side. Synology DSM CVE-2024-10441 scores 9.8, and Synology says C3RB3R ransomware is now encrypting NAS units through a flaw it fixed in late 2024. The score did its job two years ago. It flagged the bug as critical, and the units now being hit still never got the fix, likely because a NAS in a closet often sits outside the patch process entirely.

Meanwhile the two fresh 9.8s, the kernel and jackson-databind, drew the attention and had no reported attacks as of our posts. Read across all seven, the week says exploitation followed reachability and neglect: a box nobody updates, a chain link nobody prioritized, an update window that opens on every site at once, a business flaw nobody audits. The score tracked none of those.

Four questions that should outrank the score

CVSS still belongs in triage. It just should not be the first sort. Before a low or unscored bug goes into the monthly batch, ask four questions; a "yes" to any one moves it up.

1. Does it touch the evidence? Logging, audit, integrity checking, or anything that decides what gets recorded. If it does, treat it as an amplifier for every other intrusion, and list where you would still see activity if the local logs cannot be trusted (state baselines, the next hop's logs).

2. Is it a link in a listed chain? When KEV or a vendor advisory names one CVE in a product as exploited, check every other CVE in the same advisory or fix release. Score the chain by its worst outcome, not each link by its own.

3. Does it fire during routine work? Updates, backups, restores and migrations happen on schedule and at fleet scale. A narrow window that opens on every host at once is not narrow.

4. Does the damage land in data rather than on the host? Business-logic flaws in shops, billing and identity systems leave no process or file to detect. Pair the patch with a reconciliation: orders against the payment gateway, accounts against the directory.

Then set the override that this week argues for: an exploitation signal, from KEV, a vendor statement such as Drupal's, or a credible researcher report, jumps the queue regardless of score. And for each bug you promote, name the off-host evidence source before you patch, so that once it is closed you can still answer the question that actually matters: if someone used this before we fixed it, would we know?