The KEV Catalog Stopped Being a Patch List. Nobody Told the Dashboards.

There is a live example sitting in the Known Exploited Vulnerabilities catalog right now with a deadline of 18 September 2026, and it is the cleanest illustration yet of a change most vulnerability management tooling has not noticed.

The short version: KEV is no longer a list of things to patch on the same clock. It is now the input to a decision procedure with four variables, and the values for those variables are published in the feed. Almost nothing reads them.

The bug, read from the authoritative fields

CVE-2026-85046, a type confusion in V8, the JavaScript engine in Chrome and every Chromium browser. Published 3 September, analysed by 8 September, added to KEV on 4 September with a due date of 18 September.

Pulled directly from the NVD API and the CISA KEV JSON feed, rather than from coverage:

• CWE-843, type confusion, in V8
• Affects Chrome before 152.0.7977.82, V8 before 15.3.48
• CVSS 3.1 base score 8.8 HIGH, vector AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
• KEV dateAdded 2026-09-04, dueDate 2026-09-18
• knownRansomwareCampaignUse: Unknown
• forensicTriage: No
• SSVC decision points recorded on the CVE itself: exploitation = active, automatable = no, technicalImpact = total
• KEV catalog version 2026.09.11, 1,709 entries total

Two of those fields did not exist in this form a year ago, and they are the story.

The headline everyone used was wrong twice

The popular framing of this bug was "actively exploited sandbox RCE in all Chromium versions." Both halves are wrong, and the authoritative fields say so plainly.

Not all versions. The NVD record bounds it with versionEndExcluding 152.0.7977.82. There is a fixed build. That is the opposite of all versions.

Not a sandbox escape. Both NVD and CISA describe it as allowing an attacker to execute arbitrary code inside the sandbox. Look at the CVSS vector: S:U, scope unchanged. Scope is the field that exists precisely to say whether the impact crosses a security boundary, and it says no. This is stage one of a chain, not the end of one.

That distinction is not pedantry, it is the difference between a bug that needs a partner to be useful and a bug that owns the machine. If the distinction is unfamiliar, what a sandbox escape actually is walks through it with this exact CVE as the worked example.

The cheap habit worth forming: before repeating a severity claim, open the NVD API record and read the vector string. It takes a minute and it is authoritative in a way that a headline is not.

What actually changed in the policy

Binding Operational Directive 26-04, issued 10 June 2026, binds federal civilian agencies and, as usual, will set the template that private vulnerability management copies within about eighteen months.

The old model was flat. In KEV means patch by the due date. One rule, easy to implement, easy to audit, and indifferent to whether the affected system was an internet-facing gateway or a lab VM nobody can reach.

The new model prices four variables:

• Asset exposure. Internet-facing or not.
• KEV status. Known exploited or not.
• Exploit automation. Can this be weaponised at scale or does each target need hands.
• Technical impact. Partial or total control.

The last two are the interesting ones because they are now published per-CVE as machine-readable SSVC decision points, and they can contradict the severity score in operationally important ways.

Why automatable equals no changes the instruction

Look again at our example. CVSS 8.8, actively exploited, and automatable = no.

Under the old model those first two facts produce one instruction: critical, exploited, patch now, everything, this week.

The third fact says something different. Not automatable means an attacker cannot spray this across the internet and collect shells. Each target needs a user to visit a page, which means targeting, which means an adversary spends this on someone specific rather than on everyone. Combine with technicalImpact = total and S:U and the actual risk profile is: serious, chainable, aimed, and not a worm.

That does not mean do not patch. It is exploited and it has a federal deadline. It means the order changes. Exposed, automatable, total-impact issues come first; this sits just behind them. When you have forty open items and capacity for twelve this week, ordering is the only decision that exists, and CVSS alone has never been able to produce it.

This is the gap. SSVC has existed for years as a sensible academic proposal that nobody had to use. It is now binding policy with the values shipped in the feed, and most dashboards still render a number between 0 and 10 and sort descending.

The obligation people will miss

BOD 26-04 also adds something that is not patching at all.

For the highest tier, the requirement is to complete remediation within the timeline, described in the guidance as three days, and then carry out a forensic triage of the asset to assess whether the system is compromised.

That is a different kind of work with a different budget. Patching is a change ticket. Forensic triage is an investigation: acquire, preserve, examine, conclude. Most organisations have a process for the first and improvise the second.

Which is why the forensicTriage field is now in the KEV JSON per entry. On our example it reads No. On others it will read yes, and that flag is the difference between an afternoon and a week. If your pipeline ingests KEV and drops that field, you will find out about it during an incident.

The clock also starts earlier than people assume. It begins when CISA adds the vulnerability to KEV or when the agency itself identifies the vulnerability, whichever comes first. Finding it yourself starts your own timer, which removes the incentive to not look.

One caution: the directive's detailed tier deadlines live in a table rendered as a graphic on the CISA page and are not machine-extractable. The three-day figure above is quoted from the implementation guidance text. If you need the exact per-tier numbers, open the source rather than trusting any summary, including this one.

What to do this week

Check whether your scanner surfaces the SSVC fields. Search your vulnerability data for automatable or technicalImpact. If they are absent, you are running the old model on top of a feed that now carries the new one, and the sort order on your dashboard is worse than the data you already have.

Check whether you ingest forensicTriage. It is a boolean that changes the shape of the response. It is cheap to parse and expensive to discover late.

Stop treating the KEV due date as the priority signal. The due date is a compliance floor, identical across entries of wildly different urgency. The decision points are the priority signal now.

And patch CVE-2026-85046. Chrome 152.0.7977.82 or later. It is exploited, the deadline is 18 September, and none of the analysis above is an argument for waiting.

The shift underneath

The severity-number regime is ending, and it should. A single scalar was always a compression of several independent questions into one number that then got sorted descending and called a priority.

What replaces it is more honest and more work: is it being exploited, can it be exploited at scale, how exposed is this asset, and how bad is full success. Four questions, four answers, no compression.

The values are already in the feed. The tooling is the lagging part.

Sources. BOD 26-04 and its implementation guidance, CISA, 10 June 2026; the KEV JSON feed, catalog version 2026.09.11; the NVD 2.0 API record for CVE-2026-85046; and the Chrome stable channel update. Related here: what is a sandbox escape and six hours from foothold to campaign.