Microsoft updated its July 2026 Security Update release notes on 25 August to mark CVE-2026-58644 and CVE-2026-56164 as having exploitation detected. The flaws affect self-hosted SharePoint Server 2016, SharePoint Server 2019 and SharePoint Server Subscription Edition, not SharePoint Online. Organisations that cannot show every server is on a fixed build should prioritise patching, while farms exposed to the internet before remediation should be treated as potential intrusion points and assessed for compromise.

There is an important distinction in the news. The fixes were issued on 14 July 2026, and public-sector cyber agencies had already described active exploitation during July. Microsoft’s 25 August change was to its own exploitation status in the release note. That matters because these can no longer be treated as theoretical patch-management items.

This affects SharePoint Server Subscription Edition, SharePoint Server 2019 and SharePoint Server 2016: the self-hosted product installed in an organisation’s own environment or hosted by a service provider. Microsoft’s advisories and update guidance do not list SharePoint Online as an affected product. Hybrid identity, publishing and integration arrangements still warrant attention, but a Microsoft 365-only customer does not need to patch a service Microsoft operates.

The practical judgement: treat an internet-facing SharePoint Server farm, a group of SharePoint servers managed together, that was below the July fixed level as a potential intrusion point, even after patching. The patch closes the route in; it cannot show whether somebody used it beforehand.

Risk in plain English

CVE-2026-58644 is the more immediately serious vulnerability. Microsoft describes it as deserialisation of untrusted data in SharePoint, allowing an unauthorised attacker to execute code across the network. Deserialisation turns supplied data back into an application object; if hostile input is handled unsafely, it can become a route to attacker-controlled code execution. Microsoft rates it Critical, with a Common Vulnerability Scoring System (CVSS) 3.1 score of 9.8.

CVE-2026-56164 is categorised as missing authentication for a critical function. In practical terms, it can let an unauthorised network attacker obtain greater privileges than they should have. It sounds less dramatic than RCE, but that is no comfort. Privilege escalation is valuable in a chained intrusion, particularly where SharePoint has trusted connections to Active Directory, SQL Server, file stores, workflow services and line-of-business systems.

Confirmed fact: Microsoft now says exploitation has been detected for both CVEs. The US Cybersecurity and Infrastructure Security Agency (CISA) placed CVE-2026-56164 in its Known Exploited Vulnerabilities catalogue on 14 July and added CVE-2026-58644 on 16 July. CISA’s earlier advisory also warned that the wider SharePoint exploitation activity involved post-compromise behaviour including theft of Internet Information Services (IIS) machine keys and persistence activity. Checking that the public site still works is not meaningful validation.

Analysis: the risk isn’t limited to organisations that regard SharePoint as a public intranet. An externally reachable collaboration portal is the obvious priority, but internal-only farms need urgent attention too. Virtual private network (VPN) access, a compromised user device, an exposed reverse proxy, partner connectivity or an overly broad network segment can quickly change what “internal only” means.

What is affected, and what counts as fixed

Microsoft lists SharePoint Enterprise Server 2016, SharePoint Server 2019 and SharePoint Server Subscription Edition as affected by both vulnerabilities. The minimum fixed builds differ slightly between the two CVEs, so use the higher relevant level and, preferably, install the latest cumulative public update rather than stopping at a July baseline.

Product Fixed baseline for both CVEs Latest August 2026 update to deploy
SharePoint Server 2016 16.0.5561.1001 or later KB5002905; also deploy KB5002906 where the language pack is installed
SharePoint Server 2019 16.0.10417.20175 or later KB5002894, build 16.0.10417.20198; also deploy KB5002896 where the language pack is installed
SharePoint Server Subscription Edition 16.0.19725.20434 or later KB5002893, build 16.0.19725.20522

Microsoft’s SharePoint update history contains an operational detail that is easy to miss in an urgent change window: updates are cumulative. For SharePoint 2016 and 2019, farms using language packs need the appropriate language package as well as the core update to be fully current. Subscription Edition uses a single monthly package under Microsoft’s newer servicing model.

Don’t mistake a successful download for completed remediation. Confirm installation on every web front end and application server, run the SharePoint Products Configuration Wizard or the established farm deployment process, check that the farm is healthy, and record the resulting build level. A mixed farm is not a patched farm.

How exposure becomes an incident

In practical terms, it can let an unauthorised network attacker obtain greater privileges than they should have.

The most exposed systems are SharePoint web applications available directly from the internet, whether published through a reverse proxy, web application firewall (WAF) or cloud edge. Those controls still matter, but they do not prove a vulnerable SharePoint back end was unreachable. Review the actual published paths, historical firewall and proxy logs, Domain Name System (DNS) names, load-balancer configuration and any temporary access arrangements made for suppliers or remote working.

Microsoft’s hardening guidance is clear that Central Administration should not be externally accessible. It also recommends firewall separation between farm servers and external requests. That is baseline engineering, not a substitute for the updates. Network restriction reduces exposure while patching and assessment are under way; it does not remove the need to investigate a previously exposed vulnerable server.

Priority actions for UK and Channel Islands organisations

What to do next

  1. Find every farm and every server today. Include disaster-recovery instances, dormant project farms, supplier-managed installations and servers behind old DNS records. Establish the installed SharePoint build and whether language packs are present.
  2. Patch to the current August update level. Apply KB5002905/KB5002906 for SharePoint 2016 where applicable, KB5002894/KB5002896 for SharePoint 2019 where applicable, or KB5002893 for Subscription Edition. Treat the July levels as the minimum security floor, not the preferred stopping point.
  3. Prioritise exposed farms and privileged deployments. A public-facing farm, a farm with broad Active Directory permissions, or one integrated with sensitive document repositories needs the earliest maintenance window and the deepest review.
  4. Preserve and review evidence before routine clean-up. Retain relevant IIS logs, SharePoint Unified Logging Service logs, Windows event logs, proxy and WAF records, endpoint-security telemetry, authentication events and change records. Look for unfamiliar processes, scheduled tasks, services, new local accounts, altered web content, unexpected outbound connections and anomalous administrative or service-account sign-ins.
  5. Check secrets, not just files. Where compromise is suspected, involve incident-response personnel before returning the service to normal. Assess SharePoint and IIS-related cryptographic material, farm and service credentials, application secrets, administrator accounts and access tokens for rotation. Rotate in a controlled order to avoid breaking a live farm while leaving an attacker’s access intact.
  6. Validate AMSI protection. Antimalware Scan Interface integration gives SharePoint another chance to inspect malicious web requests before they are processed. CISA recommends ensuring it is enabled for each web application and using Full request-body scanning where feasible. It is a compensating control, not a replacement for patching, and Subscription Edition is the only edition with request-body scanning.

For smaller public bodies, legal firms, financial-services businesses and managed-service customers in the Channel Islands, the hard part may be ownership rather than technology. SharePoint is often quietly operated by an offshore group company, a regional provider or a former supplier. Ask a specific question: which SharePoint Server build is installed on each server, when was the July or August update applied, and has the provider assessed prior internet exposure? “Microsoft 365 is patched” is not an answer if a separate on-premises farm exists.

What good looks like after the emergency change

A good response produces evidence, not reassurance. The organisation should be able to show its server inventory, final builds, package and configuration completion, externally reachable endpoints, retained logs, investigation decisions and any identity or secret-rotation actions. If there is evidence of compromise, the next step is containment and specialist investigation, not an optimistic declaration that the patch solved everything.

AMSI is useful as an additional inspection control. Microsoft says its SharePoint integration scans HTTP and HTTPS requests using an AMSI-capable anti-malware engine. On Subscription Edition, Full Mode extends inspection to request bodies for most endpoints, with some exclusions to balance performance. Test it on representative workloads after enabling it; a security setting that cripples a business-critical publishing workflow will be bypassed or disabled under pressure.

Identity also needs proper attention. If a SharePoint compromise reaches credentials, service accounts or authentication material, the impact can extend beyond the portal itself. Identity and OAuth, an authorisation framework, are core recovery dependencies, not a post-incident tidy-up task. Nor should organisations assume multi-factor authentication (MFA) protects every session or server-side secret once an attacker is inside; session theft is a separate concern, as shown by research into stolen Microsoft 365 sessions after MFA.

Residual risk: patching is necessary, not retrospective protection

Microsoft’s 25 August update is an escalation in certainty, not a newly discovered July flaw. Fixes have been available since 14 July, while CISA and CERT-EU had already reported exploitation activity. Organisations that patched promptly and can account for their exposure have a different risk profile from those that discover an unpatched, publicly reachable server today.

The operational rule is simple. If a vulnerable SharePoint Server was exposed to untrusted networks after these flaws became known, patch it immediately, preserve evidence and assess whether it has already been used. This is not a routine update or a full-scale crisis by default. It is an urgent, evidence-led containment job.

Spot an error?

If something factual looks wrong, outdated or misleading, flag it here. Corrections are reviewed separately from normal article comments and reader questions.