CISA KEV August 2026: four exploited flaws, one weekend

Saturday morning, coffee, and the KEV feed has four new rows in it. CISA added them all on Tuesday 18 August: an improper authentication flaw in macOS that lets someone on the network log into Screen Sharing without valid credentials, a weak authentication flaw in SharePoint Server, a path traversal in VMware vCenter that ends in remote code execution, and a double free in the Windows IKE service, also ending in remote code execution. All four are confirmed exploited in the wild. All four have vendor fixes available. If you run mixed on-prem and cloud like most ANZ mid-market shops, at least two of these are in your estate right now, and the question is not whether to patch. It is which order you burn the weekend window on.

TL;DR

• CISA added four flaws to the Known Exploited Vulnerabilities catalog on 18 August 2026: CVE-2026-65400 (Apple macOS, CVSS 9.8), CVE-2026-55040 (Microsoft SharePoint, CVSS 9.1), CVE-2026-59310 (VMware vCenter, CVSS 9.8), and CVE-2026-33824 (Windows IKE service extensions, CVSS 9.8).
• All four are being exploited in the wild right now, per CISA and multiple public reports. This is not a severity spreadsheet. It is a who-is-already-inside list.
• My patch order for a typical ANZ SMB: vCenter first, Windows IKE second, SharePoint Server third, macOS fourth. Exposure can and should override that order, and I say how below.
• The US federal deadline under BOD 26-04 was Friday 21 August. It has passed. Your weekend window is the only slack left.
• Separately, Microsoft patched a maximum-severity Entra ID flaw this week, then retracted its own exploited-in-the-wild flag on it. Not one of the four. Do not let it jump your queue.

What you need to do: snapshot and patch vCenter tonight, push the Windows update to your RRAS and VPN boxes, schedule the SharePoint cumulative update for Sunday, push the macOS fix through MDM on Monday.

By The Numbers

Catalog version at time of writing: 2026.08.21, released 21 August, 1,674 total entries.

The order I would burn the window on

CVSS will not give you this order. Three of the four score 9.8, so the scores tie and you learn nothing. The right axis is exposure times blast radius times who is actually holding the exploit. Here is my order for a typical mixed ANZ SMB estate, with the reasoning.

1. vCenter, CVE-2026-59310, tonight. vCenter is the management plane for your entire virtual estate. A network-reachable path traversal ending in code execution on that box is not one server at risk, it is every VM on every host vCenter controls. The reporting is also the ugliest of the four: a suspected China-nexus APT dropping backdoors and reverse_ssh binaries for persistence, 361 unique victim IP addresses across 47 countries so far, and at least one victim hit with Babuk-derived ransomware. Take the snapshot, take the backup, check the backup, then patch. If your vCenter is internet-facing, this stopped being a weekend item the moment CISA pressed publish.

2. Windows IKE, CVE-2026-33824, tonight as well if you can. A double free in the IKE Service Extensions means pre-authentication remote code execution on any Windows box running that service, which in an SMB usually means your RRAS or VPN edge. Your VPN server is by definition internet-facing. The fix is a normal Windows update with low rollback risk: one reboot of boxes you can bounce on a Saturday. Check which servers actually run the IKE and AuthIP keying modules before panic-patching all of them. The MSRC entry for CVE-2026-33824 has the affected builds.

3. SharePoint Server, CVE-2026-55040, Sunday. A weak authentication flaw that lets an unauthorised attacker bypass a security feature over a network, with a public proof-of-concept already out and unknown actors using it. SharePoint usually carries the most change-management baggage in an SMB: it is the intranet, the document management system, and someone's workflow all at once. That is exactly why it gets the Sunday slot: the longest quiet window you have, with Monday morning as the rollback runway. If SharePoint is your only internet-facing item of the four, it swaps to first and vCenter drops to second.

4. macOS, CVE-2026-65400, Monday via MDM. An attacker already on the network can authenticate to Screen Sharing without valid credentials, and the observed payload is a Monero miner rather than a wiper or ransomware. Commodity, noisy, survivable. If your Macs are current and your MDM is healthy this is a routine push with near-zero rollback risk. 9.8 is the score, but the outcome profile puts it fourth in my queue. Screen Sharing disabled fleet-wide drops the exposure further, and you still patch because the push is free.

The KEV list is not a severity chart. It is a record of doors that are already open. Patch the door that lets the most through first, not the one with the biggest number.

My order assumes a typical exposure pattern. Yours should be built from your own edge inventory: ten minutes with your firewall rules beats any priority list on the internet, including this one.

What the exploitation reporting actually says

The KEV entries themselves are terse: product, flaw, date added, required action. The colour comes from the reporting around them, and it is worth knowing what is confirmed versus claimed.

The macOS flaw is being abused to deliver a Monero cryptocurrency miner, per The Hacker News. Miners are the least scary payload in the catalogue, but improper authentication on a remote-access service is how it got in, and the same hole carries anything else.

The SharePoint flaw moved to active exploitation after a proof-of-concept went public. Public PoC plus weak authentication is the combination that turns a niche server bug into a spray-and-pray target inside a week.

The vCenter flaw has the most detailed victim reporting: 361 unique victim IPs across 47 countries, concentrated in Germany, the US, Turkey, Iran and France, with reverse_ssh persistence and one confirmed Babuk-derived ransomware deployment. Note that CISA's KEV records still list ransomware campaign use as Unknown for all four. The ransomware link is The Hacker News relaying researcher reporting, not a CISA field. Treat it as attributed evidence and patch as if it is true, because the downside is asymmetric.

The IKE flaw, per Palo Alto Networks Unit 42, is being used by a Chinese-speaking threat actor running an AI-enabled autonomous hacking campaign built on DeepSeek, alongside manual operations against known vulnerabilities. Set the AI commentary aside. The operational takeaway is old and boring: attacker exploit inventory now refreshes faster than most SMB patch cycles.

How this differs from the Patch Tuesday list and the last KEV post

If you read the 11 August Patch Tuesday piece, this is a different question. That was 398 Microsoft fixes and a triage sprint across a whole catalogue. This is four flaws across four vendors, all confirmed exploited. One is monthly and Microsoft-only. The other is interrupt-driven and cross-vendor.

And if you read the July piece on claimed KEV additions, this is the mirror image. That story was three CVEs that failed verification, and the lesson was prove the alert before you patch. This one passes: I checked all four identifiers against the machine-readable KEV catalog, version 2026.08.21, and all four are there with a date added of 18 August 2026. Verification still comes first. It just takes two minutes this time, and then the real work starts.

The Entra ID footnote

On Thursday Microsoft published advisories for a batch of maximum-severity cloud flaws, including CVE-2026-69836 in Entra ID, reported at CVSS 10.0: deserialisation of untrusted data letting an unauthenticated attacker execute code over a network. BleepingComputer covered it on 21 August.

Here is the part worth internalising: Microsoft initially flagged it as exploited in the wild, then corrected itself and said the flag was a mistake. No exploit code is public, the cloud-side fix is already deployed, and tenants need do nothing.

A 10.0 Entra flaw that is not on the KEV list, is not exploited, and needs nothing from you should not displace a 9.1 SharePoint flaw with a public PoC that is on it. When a week gets noisy, the KEV catalog is the tiebreaker. That is the point of it.

Same week at CISA: the OT corner

CISA also published advisory AA26-231A on 19 August with the NSA, FBI, Department of Energy and other agencies: an active threat to Siemens S7 series PLCs. Unless you run plant floor or building control gear, this is an awareness item. If you do run OT, the mitigations start with inventory, patching, and making sure no PLC answers to the internet. File it under next week.

The weekend runbook

• Confirm which of the four products you actually run, and which versions.
• Snapshot and back up vCenter before touching it. Verify the backup.
• Identify Windows boxes running IKE and AuthIP keying modules. Patch and reboot.
• Patch vCenter. Check the web client, SSO login, and host connections after.
• Apply the SharePoint cumulative update in the Sunday window. Test search and the intranet homepage before you call it done.
• Push the macOS update through MDM. Verify installation rate on Monday.
• On everything patched, hunt for the signs the vendors describe: unfamiliar Screen Sharing sessions, reverse_ssh or unknown binaries on vCenter hosts, anomalous IKE service crashes.
• Write down what you deferred and why, so next week's you does not re-triage from zero.

FAQ

We use SharePoint in Microsoft 365, not SharePoint Server. Are we affected? No. The KEV entry and the MSRC advisory point at on-premises SharePoint Server. If your SharePoint is a yourtenant.sharepoint.com URL, the patch is Microsoft's job and it is already done. Your on-prem file servers are a different conversation.

Screen Sharing is disabled on all our Macs. Can we skip it? You can deprioritise it, not skip it. If the service is not listening, there is no door to walk through today, but a config drift or a re-enabled service puts it back. The fix is a free MDM push in the normal cycle. Take the free win.

Our vCenter is internal-only on a segmented management network. Can it wait a week? Defensibly, yes, if the segmentation is real and tested rather than assumed. Weigh it honestly: the campaign reporting shows hundreds of victims and ransomware in the chain. At minimum, snapshot tonight and patch in the next window you actually keep.

We are not a US federal agency. Does the 21 August deadline apply to us? No. BOD 26-04 binds US federal civilian agencies. For an ANZ SMB the KEV catalog is a free prioritisation signal, not a mandate. The reason to act this weekend is the exploitation reporting, not the deadline. The deadline just tells you how fast a large, slow bureaucracy decided the risk moved.

All four KEV entries say ransomware use Unknown. Does that mean no ransomware risk? It means the field lags. CISA marked all four Unknown while researchers were already reporting a Babuk-derived deployment in a vCenter case. Unknown is not the same as none. It is often just early.

Further Reading

• The Hacker News: macOS, SharePoint, vCenter and Microsoft IKE flaws under active exploitation - the 19 August summary of all four KEV additions
• CISA KEV catalog JSON feed - verify every CVE yourself, two minutes, no trust required
• CISA KEV catalog - the human-readable version
• MSRC: CVE-2026-55040 - affected SharePoint Server builds and the fix
• MSRC: CVE-2026-33824 - the IKE Service Extensions advisory
• Broadcom advisory 38017: vCenter - fixed vCenter builds
• Apple support: HT148170, HT148171, HT148172 - the macOS branches and their fixes
• BleepingComputer: max severity Entra ID flaws - including the retracted exploited flag
• CISA advisory AA26-231A: Siemens S7 PLCs - the OT-side read for the same week
• Patch Tuesday August 2026: 398 fixes - the monthly Microsoft sprint this is not
• Three claimed CISA KEV additions: the verification checklist - the mirror-image story from July
• The Swiss government SharePoint breach - why SharePoint intrusions are not theoretical this year

Forward this to whoever owns your change calendar, preferably before they book the weekend off.

Mathew Clark Founder, SecureInSeconds Currently: three snapshots deep and refusing to trust a green tick until the services answer.