CISA KEV, September 2026: patch, then assume compromise

This page tracks CISA's Known Exploited Vulnerabilities catalog through 2026, not just one month's additions. Each update below is dated, and nothing dated earlier is rewritten as facts change — it stays as written, correct for the day it was posted.

On August 18, 2026, CISA added four vulnerabilities to its Known Exploited Vulnerabilities catalog. Three of them sit in the middle of an ordinary mid-market estate: VMware vCenter, Microsoft SharePoint, and the Windows IKE service. All four carry a remediation due date of August 21.

Most of what you will read about this over the next week will tell you to patch. That advice is correct and it is also the easy half. This post is about the harder half, and about two details that are easy to get wrong in the direction of sounding more alarming than the facts support.

What landed, in CISA's own words

Taken directly from the KEV catalog feed (catalog version 2026.08.18):

All four are recorded with knownRansomwareCampaignUse: Unknown. Read that as not established, not as ruled out — it is an absence of evidence in CISA's record, and treating it as an all-clear is exactly the kind of small misreading that turns into a wrong sentence in a board update.

Two things not to get wrong

1. The three-day clock is the norm, not an alarm

A remediation deadline three days after listing looks like a five-alarm signal. It is not. When we first measured this in August 2026, eleven of the twelve most recent KEV additions carried a due date exactly three days out, with a single exception at fourteen. Three days was simply the shape of a KEV entry under the current directive.

We re-measured on September 5, 2026, and the pattern has moved: the fourteen most recent additions split evenly, seven at three days and seven at fourteen. That does not weaken the point — it sharpens it. A due date that ranges from three days to fourteen across the same fortnight is a scheduling convention, not a severity rating. If you were reading the clock as a measure of how bad something is, it has just told you two different things about vulnerabilities that are all, equally, being exploited.

Amended September 9, 2026 — and this is a correction, not an addition. We called the spread a scheduling convention. That was too generous to our own argument. We re-measured the whole catalog on September 9, 2026 (catalog version 2026.09.09, 1,703 records) and the clock is not arbitrary after all — it just does not track severity. It tracks something else, and that something else is a separate field sitting in the same record. The next section is that field.

This matters because the temptation is to lead with "CISA gave organizations only 72 hours." It reads well, and it is wrong — or at least, it says something about CISA's standard cadence rather than about these three vulnerabilities. The signal worth carrying to your leadership is not the clock. It is that CISA lists what is actively being exploited, and three of the four are in your estate.

2. The deadline is not yours

The due date comes from Binding Operational Directive 26-04, Prioritizing Security Updates Based on Risk, issued June 10, 2026. A BOD is a compulsory instruction to Federal Civilian Executive Branch agencies. It does not bind private-sector organizations, and it carves out statutorily defined national security systems along with certain Department of War and Intelligence Community systems. CISA encourages everyone else to use it as guidance.

So if you are a 200-person manufacturer in Bothell, nothing legally obliges you to remediate by August 21. Saying otherwise to a client — or letting a vendor say it to you — is a compliance claim that does not survive being checked.

The part worth copying: patch, then assume compromise

Here is the genuinely useful idea inside BOD 26-04, and it is the one almost nobody is writing about. The directive does not only tell agencies to patch faster. It requires them to perform forensic triage to determine whether affected systems may already have been compromised.

That sequencing is the whole point. A vulnerability is on the KEV catalog because it is being exploited. If your vCenter or SharePoint server was internet-reachable and unpatched during that window, patching closes the door — it tells you nothing about whether anyone already walked through it. Treating the patch as the end of the incident is how dwell time gets measured in months.

For a mid-market estate, forensic triage does not mean retaining an incident-response firm on day one. It means a bounded set of questions, asked in the exposure window rather than across all history:

• Was it reachable? Establish whether the affected service was exposed to the internet, and for how long. This single answer changes the size of everything below it.
• Authentication anomalies. Successful logins from unfamiliar geographies or ASNs, service accounts authenticating interactively, sessions outside normal hours.
• New persistence. Accounts, API tokens, SSH keys, scheduled tasks and services created during the window. For vCenter specifically, check for local accounts and altered permissions on the management plane.
• Outbound connections. Egress from a management host to anything it has no business talking to — a hypervisor management server should have a boring, predictable outbound profile.
• Log integrity. Gaps, truncation, or logging quietly disabled during the window. Missing logs are a finding, not an inconvenience.

If any of those come back positive, stop and escalate. If they all come back clean, you have something better than a patched server: you have a defensible, dated statement that you checked — which is what a regulator, an insurer or a customer's security questionnaire is actually going to ask for.

Update — September 2026: you can now look up whether CISA thinks you should go hunting

Everything above was written as an argument. As of this update it is also a field you can read. Every record in the KEV catalog carries a forensicTriage flag, and it answers, per vulnerability, the exact question this post has been asking: is patching enough, or should you also go and look?

Two things about that flag are worth stating carefully, because the obvious reading of it is wrong.

First, the flag is old and the "yes" is new. Every one of the 1,703 records carries the field, including entries going back to 2021. But only 48 of them are set to Yes, and the earliest of those was added on July 1, 2026 — three weeks after BOD 26-04 was issued. So this is not a new column in the catalog. It is a new judgement being applied to a small, deliberately chosen subset: roughly one KEV entry in thirty-five.

Second, the relationship to the clock runs one way only. All 48 of the forensicTriage: Yes records carry a three-day due date — 48 out of 48, no exceptions. It is tempting to flip that around and read a three-day clock as a triage signal. Do not. Ninety-six records carry a three-day due date, and they split forty-eight to forty-eight. A three-day clock on its own is a coin flip. The flag is the signal.

We re-measured the whole catalog the following day, and the relationship held. On September 10, 2026 the catalog moved to version 2026.09.10 and grew to 1,705 records. The forensicTriage: Yes set went to 49, and all 49 of 49 still carry a three-day due date. The three-day population went to 98, still splitting forty-nine to forty-nine. The new Yes record arrived with its three-day clock exactly as the pattern predicts. One day is a short test, but it is a second independent sample and it did not break — which is the most we can honestly say about a field CISA has not documented. That is precisely why the spread we described above looked like an arbitrary convention: we were reading the wrong field.

We measured it again a day after that, and the reverse split finally broke. On September 11, 2026 the catalog moved to version 2026.09.11. The forensicTriage: Yes set grew to 51, and all 51 of 51 still carry a three-day due date — that one-way relationship has now held across four separate measurements without a single exception. But the reverse no longer splits evenly: the three-day population reached 100, and instead of dividing down the middle it now reads 51 Yes to 49 No. The even split we reported on September 9 and 10 was a real reading at the time, not an error — it just was not a law, and a third measurement is what it took to show that.

What the flag actually sorts on becomes obvious the moment you look at what landed on three specific dates. On September 8, 9 and 11, 2026, CISA added twelve vulnerabilities:

The last four rows are the September 11, 2026 additions (catalog 2026.09.11, released 19:32 UTC). In CISA's own words, CVE-2026-84869 is an improper-privilege-management and missing-authorization flaw in ConnectWise ScreenConnect “that may allow an attacker to file transfer and execution through an active remote sessions without authorization or host confirmation.” If ScreenConnect or any other RMM sits in your stack, this is a vendor-management question as much as a patching one — see what this means if ScreenConnect or any RMM is your management plane. CVE-2026-85706 is a path traversal in GitLab Community and Enterprise Edition “that allows an unauthenticated user to read arbitrary files due to an improper path confinement and missing authentication enforcement in the repository commits API.” The two JFrog Artifactory entries are authorization flaws — one a token-scope validation gap that CISA's own description says can lead to privilege escalation, the other an authentication issue that can return an internal token to a caller when anonymous access is meant to be off. (We are paraphrasing that second pair rather than quoting CISA's text directly: the source description contains its own grammatical slip, and reproducing it as a quotation would misattribute an error to us instead of them.)

Read the two groups now that there are twelve. The seven flagged for triage are a commerce platform, a remote monitoring and management console, a VPN gateway, a firewall, a firewall manager, a remote support and access tool, and a source-code platform — every one of them reachable from outside and built to manage, move into, or move data out of other systems. The five that were not are two local privilege-escalation bugs in Windows, a browser engine flaw, and the two JFrog Artifactory authorization issues. The Windows and browser bugs fit the earlier pattern — things an attacker uses after landing, or that need a user to click something. The two JFrog entries do not fit that story as cleanly, and we would rather say so than force it: the split is CISA's judgment on each record, not something you can derive purely from the product category.

That is a genuinely useful triage input for a mid-market estate, and it costs nothing to use. When a KEV entry lands on something you run, read the forensicTriage value before you decide whether patching closes the ticket. If it says Yes, the five questions listed above are the work — not because a federal directive binds you, but because the people with the best view of what is being exploited have said, in a machine-readable field, that this is the class of bug where the patch is the easy half.

One operational note on the two Windows entries in that table, CVE-2026-85880 and CVE-2026-81963: the September 2026 security updates that close them carry a known issue on Remote Desktop Services. Microsoft's Windows Server 2022 release health page reports an issue opened September 11, 2026, status Mitigated: “After installing the September 2026 Windows security update (KB5122882), some organizations might experience issues with Remote Desktop Services (RDS).” Each version has its own originating update (Windows Server 2022: KB5122882, Windows Server 2019: KB5122876, Windows 11 24H2/25H2: KB5124008). No single package closes both CVEs: per Microsoft's September CVRF, CVE-2026-85880 is fixed by the Server 2022/2019/2016/2012 and Windows 10 packages (KB5122882, KB5122876, KB5123099, KB5122878, KB5123065, KB5123066), while CVE-2026-81963 is fixed by the Server 2025 and Windows 11 packages (KB5122871, KB5124008, KB5122880, KB5124012) — the September cycle closes both CVEs this post is telling you to patch, with each Windows version's own update closing one of the two. None of this is a reason to skip the update. It is a reason to stage RDS hosts and test before a broad rollout rather than pushing the update fleet-wide overnight. We cover the specific KBs and the mitigation in RDS can stop responding after the September 2026 update.

One caution on the arithmetic, since we made this mistake ourselves before publishing. The original sample was eight rows from September 8 and 9; small, and on the twelve rows above it still looks perfect in both directions — every Yes is three days, every No is fourteen. Across the full catalog it is not: the Yes set is clean and the clock is not. Cite the flag, not the deadline.

The vCenter detail everyone is blurring

Broadcom advisory VMSA-2026-0006.1 — published July 29, 2026 and revised August 3 — covers five CVEs. Two of them are rated CVSS 9.8 and both are unauthenticated:

• CVE-2026-59309 — an authentication bypass in the VMware Directory Service.
• CVE-2026-59310 — a directory traversal in the vCenter Syslog server leading to code execution.

Only CVE-2026-59310 is on the KEV catalog. Coverage routinely describes the exploited flaw using the authentication bypass language, which belongs to 59309. Patch both — Broadcom lists workarounds for them as, verbatim, "None" — but if you are writing this up internally, get the attribution right.

Fixed builds, from the advisory: vCenter 8.0 → 8.0 U3k or 8.0 U2f; 9.0.x → 9.0.2.0100; 9.1.x → 9.1.0.0300. ESXi 8.0 → ESXi80U3k or ESXi80U2f. If you are mid-way through a Broadcom exit, this lands squarely on the estate you are trying to leave — we cover what that does to exit sequencing in VMware after Broadcom.

Two late additions, and one CVE that arrived nine days after Patch Tuesday

Two entries were added to the catalog on September 10, 2026, both for MikroTik RouterOS — CVE-2026-86060 and CVE-2026-67277, both carrying a remediation due date of September 13. Only the first is flagged forensicTriage: Yes. We name them for completeness rather than urgency: MikroTik is not typical mid-market edge kit, and if you do not run RouterOS this pair is not your problem. The reason they are here is the pattern, not the product — that is a third consecutive week in which the catalog's additions have clustered on network edge and management-plane devices rather than on user endpoints.

Separately, and worth more of your attention: CVE-2026-70105 was released on August 20, 2026 — nine days after August's Patch Tuesday. Microsoft's own note explains why, and it is worth reading twice:

“This CVE was addressed by updates that were released in August 2026, but the CVE was inadvertently omitted from the August 2026 Security Updates.”

The fix shipped on time. The paperwork did not. If your patch process reconciles against the Patch Tuesday CVE list — and most do, because that is the list everyone publishes — then for nine days your records showed either a gap that did not exist or a coverage claim you could not evidence. Neither is a patching failure; both are a reporting failure, and an auditor cannot tell the difference from the outside. Reconcile against the month's updated CVE list rather than the one published on the day, and re-check a few days later. Microsoft amends the record after the fact more often than the monthly cadence suggests.

What we would do this week

1. Inventory before you patch. You cannot triage exposure you cannot enumerate. Find every vCenter, every on-prem or hybrid SharePoint server, and every Windows host terminating IPsec.
2. Establish internet reachability for each one. This is the variable that decides whether the next step is an afternoon or a week.
3. Patch to the fixed builds. There are no workarounds for the vCenter pair.
4. Run the triage questions above across the exposure window — not across all time, which is how this work becomes unbounded and therefore never gets done.
5. Write down what you checked and when. The dated record is the deliverable. A patch with no triage record answers none of the questions you will be asked later.

Update — September 2026: the vendor called it before the catalog did

One addition since this post went up is worth folding in, less for the vulnerability than for what its timing shows. On September 4, 2026 CISA added CVE-2026-85046 to the catalog (catalog version 2026.09.04). In CISA's words it is a "Google Chromium V8 type confusion vulnerability that allows a remote attacker to execute arbitrary code inside the sandbox via a crafted HTML page," and the entry notes it "could affect multiple web browsers that utilize Chromium, including, but not limited to, Google Chrome, Microsoft Edge, and Opera." Its due date is September 18 — fourteen days, one of the entries behind the split above.

Here is the part that matters for how you run patching. Microsoft had already shipped the fix, and already said it was being exploited, two days earlier. Microsoft's Edge security release notes for September 2, 2026 state that Edge 152.0.4191.62 "incorporates the latest Security Updates of the Chromium project," and that "the Chromium team reported that CVE-2026-85046 has an exploit in the wild, and this update contains a fix for it." A further release, 152.0.4191.66, followed on September 4.

The practical check is short: confirm your Edge and Chrome update channels are current and actually delivering, rather than assuming they are. Managed browsers frequently stop updating for reasons nobody notices until someone looks — a stalled update service, a policy pinning a version, a device that has not been online long enough to complete a download.

One boundary is worth drawing explicitly, because it decides what a patch-compliance report can and cannot tell you. Everything above is a CVE you can act on: there is a fixed build, and a host you own to install it on. The same month produced six CVSS 10.0 flaws with neither — in Microsoft's own cloud services, already fixed by Microsoft, with no customer artifact to patch. A report that counts patched hosts is structurally silent on them. That is the cloud-service CVEs you cannot patch.

And once, the coverage was ahead of both

The section above is about a vendor moving before the catalog. This is the same gap running the other way, and it is the one more likely to waste your week: coverage moving ahead of both.

Through early September, security coverage described CVE-2026-62911 as a critical authentication bypass in Microsoft Exchange Server under active exploitation, with headline counts of more than 21,000 exposed servers. If you run Exchange on-premises, that is a sentence that reorganizes your day.

Microsoft's own machine-readable security record says something different. In the August 2026 security update revision, the entry is titled Microsoft Exchange Server Elevation of Privilege Vulnerability — not an authentication bypass. Its exploitability string reads “Publicly Disclosed:No;Exploited:No;Latest Software Release:Exploitation Less Likely.” Its CVSS base score is 8.0, and the vector is AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C.

Two fields in that vector do the work. PR:L means the attacker already needs privileges on the system. UI:R means a user has to do something. A flaw requiring both is the opposite of an unauthenticated bypass, which by definition requires neither. And E:U — exploit code “unproven” — is Microsoft's own statement that it has not seen working exploitation.

The independent check agrees. As of the catalog released September 4, 2026, CVE-2026-62911 is not in CISA's Known Exploited Vulnerabilities catalog — the same catalog this post is about, which lists 1,695 entries and exists precisely to record vulnerabilities under active exploitation. Two independent authorities, neither of them saying what the coverage said.

None of which makes it something to ignore. It affects Exchange Server 2016 CU23, Exchange Server 2019 CU14 and CU15, and Exchange Server Subscription Edition RTM, and Microsoft has shipped a fix in KB5121576. Patch it on your normal cycle. The point is that “normal cycle” is the right answer here, and “drop everything” was not — and the difference between those two came from reading the vendor's record instead of the coverage of it.

Two dates to hold onto, because both of these move: Microsoft's exploitability fields are updated as it learns more, and CISA adds to KEV daily. Everything above is as of September 5, 2026. If exploitation is confirmed later, the record will say so — and that record, not the headline, is still where you should read it.

Two more KEV additions worth naming, because of where they live

On August 31, 2026 CISA added two PaperCut NG/MF vulnerabilities: CVE-2026-81578 (missing authentication for a critical function) and CVE-2026-82078 (unsafe reflection), both with a federal remediation due date of September 14, 2026. Reporting through the first week of September described exploitation against schools and universities.

The reason it belongs in this post is the mechanism rather than the CVEs. Print management sits in the category of infrastructure nobody lists as a security asset, and a PaperCut server is frequently configured with directory credentials so it can look users up. That makes a print server a place where domain credentials are stored — which is what turns a print-server vulnerability into lateral movement. The pattern in this post applies without modification: patch it, then go and look, because the thing worth finding is what was done with the access, not the vulnerability itself.

As always, the federal due date binds federal civilian agencies. It is not your deadline. It is a useful signal about how quickly the government thinks this needs to be gone.

If you want this run as a bounded piece of work rather than added to an already-full internal queue, scope it with us — inventory, patch, triage and a dated findings record, on a fixed-fee basis.