Field notes · 6 min read ·
ShareCISA KEV, August 2026: patch, then assume compromise
CISA added vCenter (CVE-2026-59310), SharePoint (CVE-2026-55040) and Windows IKE (CVE-2026-33824) to the KEV catalog on August 18, 2026. The August 21 due date binds federal civilian agencies, not private companies — but a KEV listing means active exploitation. Patch, then check whether you were already hit.
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):
| CVE | Product | CISA's description | Due |
|---|---|---|---|
CVE-2026-59310 | Broadcom VMware vCenter | A path traversal "which could allow a threat actor with network access to vCenter to execute arbitrary code" (CWE-22) | 2026-08-21 |
CVE-2026-55040 | Microsoft SharePoint | A weak authentication vulnerability "which allows an unauthorized attacker to bypass a security feature over a network" (CWE-1390) | 2026-08-21 |
CVE-2026-33824 | Microsoft IKE Service Extensions | A double free "that could enable remote code execution" (CWE-415) | 2026-08-21 |
CVE-2026-65400 | Apple macOS | Added the same day; outside the scope of this post | 2026-08-21 |
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. Of the twelve most recent KEV additions, eleven carry a due date exactly three days out; the single exception ran fourteen. Three days is simply the shape of a KEV entry under the current directive.
This matters because the temptation is to lead with "CISA gave organisations 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 organisations, 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.
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.
What we would do this week
- 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.
- Establish internet reachability for each one. This is the variable that decides whether the next step is an afternoon or a week.
- Patch to the fixed builds. There are no workarounds for the vCenter pair.
- 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.
- 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.
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.
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.
Questions we get asked
- Does the CISA KEV August 21 deadline apply to my company?
- Almost certainly not as a legal obligation. The remediation due date attached to a KEV entry is set by Binding Operational Directive 26-04, issued June 10, 2026, and a BOD is compulsory only for Federal Civilian Executive Branch agencies. It does not bind private-sector companies, and it explicitly excludes statutorily defined national security systems and certain Department of War and Intelligence Community systems. CISA encourages state, local and private-sector organisations to use it as guidance. So August 21 is not your deadline — but the reason the entry exists is that the vulnerability is being exploited right now, and that applies to everyone running the software. If you hold federal contracts, check your contract terms and your prime's flow-downs separately; a directive that does not bind you directly can still reach you through an agreement you signed.
- Is a three-day KEV remediation window unusually short?
- No, and it is worth knowing that before you escalate on it. Three days is the current norm: of the twelve most recent additions to the catalog, eleven carry a due date exactly three days after the date added. The one exception ran fourteen days. A short window is the standard shape of a KEV entry under BOD 26-04, not a signal that CISA considers these particular vulnerabilities more severe than others on the list. What the listing itself signals is exploitation — CISA adds entries on evidence of active exploitation in the wild, and that is the part worth acting on.
- Which vulnerabilities did CISA add on August 18, 2026?
- Four, three of which sit in a typical mid-market Microsoft and VMware estate. CVE-2026-59310, described by CISA as a path traversal in Broadcom VMware vCenter that could allow a threat actor with network access to vCenter to execute arbitrary code. CVE-2026-55040, a weak authentication vulnerability in Microsoft SharePoint that allows an unauthorized attacker to bypass a security feature over a network. CVE-2026-33824, a double free vulnerability in Microsoft Internet Key Exchange (IKE) Service Extensions that could enable remote code execution. The fourth, CVE-2026-65400, affects Apple macOS. All four carry a remediation due date of August 21, 2026, and all four are recorded with known ransomware campaign use of Unknown.
- We patched. Are we done?
- Not under the standard the directive itself sets. BOD 26-04 requires agencies to perform forensic triage to determine whether an affected system may already have been compromised, rather than treating the patch as the end of the incident. That sequencing is the substantive idea in the directive and it transfers cleanly to a private-sector estate. A vulnerability reaches the KEV catalog because it is being exploited, which means the relevant question is not only whether you are still exposed but whether you were exposed while it was being used, and what an attacker could have done in that window. For an internet-reachable vCenter or SharePoint server, that means reviewing authentication logs, looking for accounts and scheduled tasks created in the exposure window, and checking for persistence before you close the ticket.
- Is the VMware vCenter authentication bypass the one being exploited?
- No, and this is worth getting right because coverage keeps conflating them. Broadcom advisory VMSA-2026-0006.1 covers both CVE-2026-59309, an authentication bypass in the VMware Directory Service, and CVE-2026-59310, a path traversal in the vCenter Syslog server. Both are rated CVSS 9.8 and neither requires authentication. Only CVE-2026-59310 is on the KEV catalog. Patch both — the advisory states its workarounds as, verbatim, None — but do not repeat the claim that the authentication bypass is the one under active exploitation, because the federal catalog does not say that.
Related service
Identity, Security & ComplianceWritten by the team at Pro IT NW · Senior-led Microsoft project consultancy · Seattle / USA-wide.