CISA has added four vulnerabilities to its Known Exploited Vulnerabilities catalog, including a critical Windows Internet Key Exchange vulnerability and a Microsoft SharePoint authentication flaw. For Windows and infrastructure teams, the immediate implication is clear: this is no longer a queue-sorting exercise based on theoretical severity. CISA says it has evidence that attackers are exploiting all four flaws in the wild.

The August 18 addition covers CVE-2026-33824 in Windows IKE Service Extensions, CVE-2026-55040 in on-premises Microsoft SharePoint Server, CVE-2026-59310 in Broadcom VMware vCenter, and CVE-2026-65400 in Apple macOS Screen Sharing. The four products serve very different roles, but three are frequently deployed as high-value enterprise infrastructure: remote-access endpoints, collaboration servers, and virtualization management planes.

CISA’s announcement matters most because it changes the status of vulnerabilities whose fixes had already been available for weeks or months. The agency’s catalog is a record of demonstrated exploitation, not merely public proof-of-concept code or a high CVSS rating. Administrators that treated any of these as a normal patch-cycle item should now reassess exposure, patch status, and signs of compromise.

Cybersecurity analyst monitors threat alerts and network activity across multiple dashboards.Windows IKE Extension RCE moves from theoretical to active exploitation​

CVE-2026-33824 is a double-free vulnerability in the Windows IKE Extension that allows an unauthenticated attacker to execute code over a network. Microsoft assigned it a CVSS 3.1 score of 9.8, with network reachability, low attack complexity, no required privileges or user interaction, and full impact on confidentiality, integrity, and availability.

The National Vulnerability Database’s change record shows the important shift on August 18: CISA changed the exploitation assessment for CVE-2026-33824 from “none” to “active.” CISA also classifies the flaw as automatable with total technical impact. That does not mean every Windows PC is exposed to a drive-by Internet attack. It means systems accepting relevant IKE/IPsec traffic need to be treated as an urgent perimeter problem.

The vulnerable component is used by Windows IPsec and IKE functionality, which is commonly present in Always On VPN, Remote Access, site-to-site VPN, DirectAccess-era deployments, and IPsec connection-security rules. A workstation simply having the IKE and AuthIP IPsec Keying Modules service installed is not enough to establish Internet exposure; the practical question is whether the machine can be reached over the IKE paths its configuration accepts.

Microsoft’s affected-product record spans a broad Windows estate. It includes Windows 10 1607 and 1809, Windows 10 21H2 and 22H2, and several Windows 11 releases. The documented fixed build thresholds include:

  • Windows 10 22H2 build 19045.7184.
  • Windows 11 23H2 build 22631.6936.
  • Windows 11 24H2 build 26100.8246.
  • Windows 11 25H2 build 26200.8246.
  • Windows 11 26H1 build 28000.1836.

Those version numbers are useful for asset owners because an apparently current Windows installation may not contain the April security fix if cumulative-update deployment has fallen behind. Windows Update reporting, WSUS, Configuration Manager, Intune, and endpoint-management inventories should be checked for the actual installed OS build rather than a generic “compliant” state.

The action for teams operating Windows VPN or IPsec endpoints is to patch immediately, then verify that inbound UDP 500 and UDP 4500 are limited to intended networks and gateways. If a public-facing VPN endpoint cannot be updated at once, restrict its exposure as an emergency containment step and review network and endpoint telemetry for anomalous IKE negotiation activity. Do not disable core remote-access services blindly on production systems; identify which gateways and Windows hosts actually act as IKE responders first.


SharePoint CVE-2026-55040 adds to an already difficult on-premises cleanup​

CVE-2026-55040 is a weak-authentication vulnerability in Microsoft SharePoint Server. The Canadian Centre for Cyber Security describes it as a flaw that can allow an unauthorized attacker to bypass a security feature over a network, affecting multiple on-premises SharePoint versions.

This distinction is important: the affected product is SharePoint Server, not SharePoint Online. Microsoft 365 tenants using SharePoint Online do not manage SharePoint Server binaries or apply SharePoint Server cumulative updates. The organizations that need to act are those with self-hosted SharePoint farms, including hybrid environments where an on-premises deployment remains connected to identity systems, internal data sources, or business workflows.

CVE-2026-55040 was addressed in Microsoft’s July 14 security release. The Canadian cyber agency listed fixed baselines of SharePoint Enterprise Server 2016 version 16.0.5561.1001, SharePoint Server 2019 version 16.0.10417.20175, and SharePoint Server Subscription Edition version 16.0.19725.20434. Administrators should install the latest supported SharePoint updates rather than treating those numbers as an endpoint; they establish the minimum patch level associated with this vulnerability.

The larger operational issue is that SharePoint has already been a target of active exploitation during 2026. CISA’s recent SharePoint hardening guidance tells organizations to search for web shells, suspicious worker-process activity, anomalous requests, and IIS machine-key access before considering remediation complete. It also advises against directly exposing SharePoint servers to the Internet and recommends placing unavoidable external access behind an authenticated Layer 7 reverse proxy or equivalent application-layer control.

Patching CVE-2026-55040 therefore should be bundled with a basic exposure and compromise review. Confirm whether SharePoint Central Administration is externally reachable, enumerate Internet-facing web applications, check whether AMSI is enabled for SharePoint web applications, and review IIS and SharePoint logs covering the period before the update was applied. A successful authentication bypass can be an entry point; a clean patch report does not prove that the server was not already accessed.

There is also a support-lifecycle pressure point. The Canadian Centre for Cyber Security notes that SharePoint Server 2016 and SharePoint Server 2019 reached end of life on July 14, 2026. Organizations still using those products may have installed the final security updates and remain operationally exposed to the next SharePoint flaw with no supported patch path. That makes migration to SharePoint Server Subscription Edition or a move to a service-based alternative a risk-reduction decision, not a long-range modernization project.


vCenter’s management plane cannot wait for a routine outage window​

Broadcom’s VMSA-2026-0006.1 identifies CVE-2026-59310 as a critical directory-traversal flaw in the vCenter Syslog server. According to Broadcom, a malicious actor with network access to vCenter can exploit it to execute arbitrary code. Broadcom rates the issue 9.8 out of 10 and provides no workaround.

That combination is why vCenter deserves separate treatment from ordinary virtual-machine patching. vCenter is a management-plane system with access to inventory, host configuration, virtual-machine operations, credentials, and administrative workflows. A compromise can give an intruder a route to disrupt or manipulate a large share of an organization’s compute environment from one control point.

Broadcom’s remediation matrix identifies patched releases for vCenter 8.0, VMware Cloud Foundation and vSphere Foundation 9.0 and 9.1, plus supported cloud and telco bundles. For standalone vCenter 8.0, the vendor lists 8.0 U3k and 8.0 U2f as fixed releases; version 9.0 requires 9.0.2.0100, while version 9.1 requires 9.1.0.0300. VMware Cloud Foundation 5.x needs the vendor’s asynchronous patching process to reach the relevant vCenter fix.

The key fact that can get lost in a broad advisory is that CVE-2026-59310 is paired in Broadcom’s bulletin with CVE-2026-59309, another critical vCenter vulnerability involving authentication bypass. The two flaws share the same remediation releases. Even if an organization’s immediate concern is the newly listed directory-traversal issue, patching to the supplied fixed level addresses both.

Inventory should start with every vCenter Server Appliance and any vCenter instance reachable from administrator workstations, jump hosts, monitoring systems, backup servers, or routed management networks. “Not Internet-facing” is not sufficient protection when attackers regularly use compromised endpoint credentials and internal footholds to reach management networks. Limit management-plane access, validate backup and rollback procedures, patch, and review vCenter logs and administrative events from before the maintenance window.


Apple’s Screen Sharing flaw is an exposure problem, not a generic Mac problem​

CVE-2026-65400 affects macOS Screen Sharing, Apple’s VNC-based remote desktop service. Tom’s Hardware, citing the Dutch National Cyber Security Centre, reported active attacks against Internet-exposed Macs with TCP port 5900 available; the reported incidents involved attackers obtaining root access and installing Monero cryptocurrency miners.

Apple issued an out-of-band fix on August 6 for macOS Tahoe 26.6.1, macOS Sequoia 15.7.9, and macOS Sonoma 14.8.9. Tom’s Hardware further reported that CISA increased the flaw’s score from 7.1 to 9.8 on August 14 after reassessing it as requiring no attacker privileges and enabling full system compromise. CISA’s KEV addition on August 18 converts that concern into a confirmed remediation priority.

Screen Sharing is disabled by default, so this should be handled through configuration inventory rather than a blanket assumption that every managed Mac is exposed. Verify whether Screen Sharing, Remote Management, or related remote-access services are enabled; identify systems reachable on port 5900; and disable Screen Sharing where it is unnecessary. Macs that provide remote support or lab access should receive the security update immediately and have their remote-access routes limited through VPN, firewall policy, or managed remote-support tooling.

The shared lesson across all four KEV additions is that exposure determines urgency, but active exploitation removes the option to defer. Windows IKE endpoints, on-premises SharePoint farms, vCenter management appliances, and Macs with Screen Sharing enabled should be pulled into the same incident-aware remediation process: patch to a supported fixed version, reduce reachable attack surface, and check whether the compromise happened before the update.