CISA's September 4, 2026 Known Exploited Vulnerabilities release creates three different change events, not three new vulnerabilities. Chromium V8 CVE-2026-85046 is the only new catalog member and is due September 18. Two older rows—Windows CVE-2022-37969 and end-of-life Adobe Flash Player CVE-2016-4117—remain old members but now report known ransomware campaign use as Known instead of Unknown.
That split changes the work queue. The Chromium row starts product-discovery, exposure, mitigation, and verification work. The two metadata changes reopen or enrich existing records; they do not reset their historical due dates, prove a local asset is affected, or create two new membership counts.
The question this map answers
What changed between CISA KEV versions 2026.09.02 and 2026.09.04, and how should defenders route a new catalog member differently from changed metadata on existing members?
MyMap observed the live CISA JSON, the official cisagov/kev-data mirror, its pinned schema, BOD 26-04, and Google's linked Chrome advisory at 4:03 AM Pacific Time on September 5. The feed identified itself as version 2026.09.04, recorded a release time of 9:47:03 AM Pacific Time on September 4, and contained 1,695 rows.
In this map, a membership event adds or removes a CVE ID. A metadata event changes a field on an ID present in both snapshots. A catalog fact is the value CISA publishes. A local finding joins that fact to an asset, version, exposure, deployment, evidence, or verified mitigation. Unknown means the catalog did not state known ransomware use; it is not the same as No.
The reproducible diff is one addition plus two field changes
Pin official mirror commit 782e9b63 for September 2 and ac9d3716 for September 4. Parse each vulnerabilities array, index rows by cveID, compare ID sets, then deep-compare every shared row field. That produces:
| Diff class | Result |
|---|---|
| Catalog version | 2026.09.02 → 2026.09.04 |
| Row count | 1,694 → 1,695 |
| CVEs added | 1: CVE-2026-85046 |
| CVEs removed | 0 |
| Existing rows changed | 2 |
| Changed field | knownRansomwareCampaignUse |
| Old → new value | Unknown → Known on both rows |
No other field changed on those two older rows in the pinned comparison. Their original dateAdded and dueDate values remain intact. A monitor that reports only row-count changes would see the Chromium addition but silently miss the ransomware updates. A monitor that calls every changed row “new” would overstate the September 4 additions threefold.
Chromium is one new source record with a browser-family scope problem
CISA describes CVE-2026-85046 as a type-confusion vulnerability in Chromium V8 that can let a remote attacker execute arbitrary code inside the sandbox through crafted HTML. The row says the issue can affect multiple Chromium-based browsers, including Chrome, Edge, and Opera. It lists September 4 as the date added, September 18 as the due date, Unknown ransomware use, and forensicTriage: "No".
Google's September 3 Chrome advisory identifies the same CVE as a high-severity V8 type confusion and says an exploit exists in the wild. The advisory lists Chrome 152.0.7977.82/.83 for Windows and Mac and 152.0.7977.82 for Linux, with rollout occurring over the following days or weeks.
Those sources establish a catalog and vendor starting point, not a complete inventory of every Chromium embedding. CISA names browser examples but does not publish a closed affected-product list in the row. Google's Chrome fixed versions do not by themselves establish the fixed version for Edge, Opera, Electron, an embedded WebView, or a vendor-forked runtime. Preserve the product family, distribution, V8/Chromium lineage, platform, deployed version, and vendor advisory as separate fields.
The two ransomware changes are reopen signals, not new deadlines
CVE-2022-37969 is a Microsoft Windows Common Log File System privilege-escalation entry added September 14, 2022, with an October 5, 2022 due date. CVE-2016-4117 is an Adobe Flash Player arbitrary-code-execution entry added March 3, 2022, with a March 24, 2022 due date; its required action says the end-of-life product should be disconnected if still in use.
In the September 4 snapshot, both rows change ransomware use from Unknown to Known. That is a source-state transition about campaign evidence. It does not say which ransomware family, campaign dates, victim organizations, or artifacts caused the update. The catalog rows do not prove either vulnerability is present or exploited in a reader's environment.
An operational system should attach the new fact to the existing CVE record and reopen review if policy requires. For a previously closed item, check whether the original scope evidence still covers every current asset, whether an exception or compensating control remains valid, and whether retained telemetry supports any newly required investigation. Do not generate a replacement 2026 due date; the source did not.
The raw triage field and the BOD workflow are not interchangeable
The new Chromium row carries forensicTriage: "No", while every September 4 required-action string still directs stakeholders to BOD 26-04 and the Forensics Triage Requirements. The pinned JSON schema does not define the forensicTriage property or its allowed values.
BOD 26-04 does provide a broader asset-level decision model. It uses public exposure, KEV status, exploit automation, and technical impact to set remediation timing. It says the “& forensic triage” outcome requires remediation or mitigation within three calendar days plus a forensic review of the asset, and it says timelines can change when an asset's exposure changes.
That means the catalog's raw No value should be stored, but it should not be expanded into “forensics are never needed.” The feed value, directive table, current asset exposure, automation and impact metadata, and incident evidence are separate inputs. Private organizations can use the source as risk guidance, but BOD 26-04 is a compulsory direction for covered Federal Civilian Executive Branch systems, not a universal legal deadline for every organization.
Build two event streams and one local asset join
Emit a membership stream with catalog version, release time, commit SHA, CVE ID, date added, due date, raw triage value, ransomware value, required action, and notes. The September 4 stream contains one added event.
Emit a metadata stream with CVE ID, field name, old value, new value, source version, and observation time. The September 4 stream contains two updated events. Never overwrite the prior value without history; the transition itself explains why an old ticket may need review.
Then join both streams to assets. For Chromium, search managed browser inventories, server-side browser runtimes, desktop shells, kiosk software, and other explicitly supported Chromium-derived products, but verify each with its vendor. For the older CVEs, locate surviving Windows exposure and any Flash remnants, then compare present state with the evidence recorded when the original work closed.
Closure needs runtime proof: patched or removed version on every serving process, a vendor-confirmed mitigation, or a documented scope result showing the product is absent. Package download, policy publication, and ticket status are intermediate states.
Confirmed, derived, and still unknown
CISA confirms version 2026.09.04, 1,695 rows, the Chromium CVE's description, date, due date, raw triage and ransomware values, the two older rows' new Known ransomware values, and each required action. The pinned mirror comparison confirms one addition, no removals, and two existing-row changes.
Google confirms the Chrome fixed versions listed in its September 3 advisory, rates the CVE high severity, and says an exploit exists in the wild. That advisory controls Chrome; other Chromium-derived products need their own vendor evidence.
MyMap derives the two event streams, the three-event routing map, and the local join from source facts to asset, exposure, mitigation, evidence review, and runtime verification. Those are operational structures, not CISA labels.
The sources leave unknown the complete affected-version range across every Chromium-based product; whether a reader runs an affected build; local exposure or compromise; the ransomware families and evidence behind the two field updates; whether the raw forensicTriage property will enter the published schema; and whether later catalog versions will change these rows again.
The immediate next step is to create one new Chromium work object and two metadata-review events. Route the Chromium record through each product vendor's fix evidence, retain the September 18 source date, and verify every runtime. For the older CVEs, preserve the Unknown → Known transition and reopen scope or evidence review without inventing a new deadline.