Microsoft flags exploited SharePoint Server RCE as patching priority

Microsoft has marked CVE-2026-58644, a critical remote-code-execution flaw affecting on-premises SharePoint Server, as exploited in the wild. Organisations should identify every SharePoint Server Subscription Edition, SharePoint Server 2019 and SharePoint Enterprise Server 2016 farm, confirm each server meets at least the June 2026 fixed-build threshold, and deploy the latest applicable August cumulative update. Any internet-facing server that remained below that threshold should be treated as an incident-triage priority, because patching closes the vulnerability but cannot establish whether an earlier compromise occurred.

One date needs clearing up. Microsoft’s release-note page was available and surfaced the exploitation status on 25 August 2026, but the CVE was issued on 14 July 2026 and the build thresholds for the fix point to the 9 June 2026 SharePoint updates. Calling this an August security release would be wrong. August matters as a renewed warning and a reason to check estates again; it isn’t when Microsoft first shipped the fix.

What happened

CVE-2026-58644 is a critical deserialisation flaw in Microsoft Office SharePoint that allows an unauthorised attacker to execute code over a network. Deserialisation turns received data back into objects an application can use. Get that process wrong and hostile input can be interpreted in dangerous ways. Microsoft assigned a CVSS 3.1 (Common Vulnerability Scoring System) score of 9.8, with no privileges or user interaction required.

Microsoft’s July 2026 Security Update Guide release notes mark the issue as “Exploitation Detected”. The US National Vulnerability Database also records it in CISA’s Known Exploited Vulnerabilities catalogue, with CISA’s assessment indicating active exploitation, automation potential and total technical impact. These aren’t labels to inflate a monthly patch list. They mean attackers know how to use the weakness.

The affected product family is the self-hosted SharePoint estate: SharePoint Server Subscription Edition, SharePoint Server 2019 and SharePoint Enterprise Server 2016 on x64, or 64-bit, systems. This isn’t a SharePoint Online issue simply because a business uses Microsoft 365 alongside an old intranet. That distinction matters where a legacy document portal sits behind a reverse proxy, a server that sits between users and the backend service, or a publishing farm has been forgotten altogether.

Timeline: a July warning about a June fix

The chronology is less tidy than the headline readers may have seen. Microsoft’s CVE record was published on 14 July. The available NVD configuration data identifies affected builds as those below 16.0.19725.20384 for Subscription Edition, below 16.0.10417.20153 for SharePoint Server 2019, and below 16.0.5556.1005 for SharePoint Enterprise Server 2016. Microsoft’s update history maps those thresholds to the 9 June release.

As of 26 August 2026, don’t stop at the minimum safe version. Install the current August cumulative update after normal farm planning and validation:

• SharePoint Server Subscription Edition: KB5002893, build 16.0.19725.20522, released 11 August 2026. The minimum build containing the CVE-2026-58644 fix is 16.0.19725.20384 from KB5002873.
• SharePoint Server 2019: KB5002894 plus KB5002896 where the language-dependent package applies, build 16.0.10417.20198, released 11 August 2026. The minimum fixed build is 16.0.10417.20153, delivered by KB5002874.
• SharePoint Enterprise Server 2016: KB5002905 plus KB5002906 where applicable, build 16.0.5565.1001, released 11 August 2026. The minimum fixed build is 16.0.5556.1005, delivered by KB5002880.

Microsoft describes these updates as cumulative, meaning they include prior fixes. For a normally managed farm, the current August release is the right destination rather than a superseded June package solely because it introduced this fix. For 2016 and 2019, don’t overlook the language-dependent WSSLOC update: Microsoft’s update history says both the STS and WSSLOC packages are required to fully update a farm where that package is issued.

Impact: why SharePoint deserves a different response threshold

SharePoint is often more exposed and more trusted than its owners realise. It can hold board papers, HR material, engineering drawings, contracts and operational documents, and may sit close to Active Directory, SQL Server, workflow services and other systems needed to keep a business running. Remote code execution on that host is a potential entry point, not merely a document-management defect.

That doesn’t prove data theft, ransomware deployment or a particular attacker campaign in any individual case. Microsoft’s exploitation flag confirms the vulnerability is being used; it doesn’t, by itself, identify victims, actor attribution or an observed impact in every affected organisation. Take the exposure seriously without inventing a breach narrative.

For UK and Channel Islands organisations, this includes smaller public bodies, professional-services firms and regulated businesses that may retain SharePoint farms for data-residency, integration or long-standing workflow reasons. A cloud migration programme doesn’t reduce today’s risk if an on-premises farm remains in service while the programme drifts.

Detection and response: patch, then assess the host

Internet-facing and unpatched is the highest-risk combination. Remove unnecessary public exposure now, using access controls or a maintenance window where necessary. But don’t assume a reverse-proxy rule in front of an already exposed vulnerable host closes the incident. Preserve relevant logs before routine rotation or clean-up removes useful evidence.

Review SharePoint and IIS (Internet Information Services) web-server logs for the period of exposure, Windows event telemetry, endpoint detection records, application-pool and web-worker process activity, new or unusual administrator actions, scheduled tasks and services, and unexpected outbound connections from SharePoint servers. This needs to be a broad compromise assessment, not a hunt for one fashionable indicator. Microsoft’s public CVE entry confirms exploitation but doesn’t provide a definitive standalone set of indicators that can clear a server.

CERT-EU recommends immediate updating, credential rotation for assets that may have been exposed to the internet, and a compromise assessment. That’s a proportionate baseline. Where evidence suggests execution or persistence, isolate the host under an incident-response process, investigate the wider farm and connected identity systems, and plan credential and key rotation around what the server could access. Recovery can’t stop at the web tier: email, identity and OAuth recovery planning matters because a SharePoint server compromise may be only the first visible part of a wider access problem.

Deployment considerations are real, but they are not a reason to defer

SharePoint patching can be operationally awkward. Farms need maintenance planning, package deployment and post-installation configuration through PSConfig, SharePoint’s post-install configuration tool. Microsoft also documents workflow prerequisites for the July packages: farms using SharePoint Workflow Manager need KB5002799 installed before the cumulative update, while classic Workflow Manager requires a documented configuration change to continue operating. Bring in the SharePoint owner and test carefully. Don’t leave an exploited RCE open.

There are known July-update issues for some multi-front-end SharePoint 2019 farms using Trusted Provider or Forms authentication, including repeated sign-in prompts. Microsoft says sticky sessions at the reverse proxy mitigate most cases, and explicitly advises against disabling SessionCookieTransformProtectionEnabled because it weakens farm security. The sensible trade-off is to schedule and validate the update, not to “fix” a post-patch login nuisance by switching off a security control.

Patch reliability deserves attention in its own right. An update approved but not successfully installed is no protection, as Microsoft Defender’s recent scan-crash fix highlights. Here, version verification on every server in the farm matters more than a change-ticket status saying the rollout completed.

What organisations should change after this

Make SharePoint discovery a recurring control, not an emergency spreadsheet exercise. Include externally published URLs, reverse-proxy mappings, DNS (Domain Name System) records, virtual machines, disaster-recovery sites and dormant farms. Asset inventories that only follow procurement records are particularly poor at finding collaboration systems inherited through mergers, departmental projects or old intranets.

Question whether any SharePoint Server needs direct internet exposure. CERT-EU’s advice is plain: after the run of serious SharePoint weaknesses, organisations should reconsider direct exposure altogether. A VPN (virtual private network), application proxy, conditional access layer or limited partner-access design brings inconvenience and operational dependencies, but that’s a fair trade against leaving a high-value collaboration server broadly reachable.

Set an escalation rule that recognises confirmed exploitation. Critical vulnerabilities aren’t all equal. A critical CVSS score is a severity estimate; an exploitation-detected designation is evidence about attacker behaviour. CVE-2026-58644 belongs in the latter category and should be handled accordingly.