Microsoft SharePoint RCE zero-day (CVE-2026-58644): exploited in the wild - patch every farm server now

The short version

On-premises SharePoint is one of those systems that quietly runs half the business - documents, intranets, workflows, the lot - and sits deep inside the network with a lot of trust and a lot of access. That's exactly what makes a critical remote code execution bug in it so dangerous. When one gets exploited before a patch exists, it isn't a maintenance-window problem. It's an incident-response one.

That's the situation with CVE-2026-58644, a critical RCE flaw in supported on-premises Microsoft SharePoint Server. Microsoft has confirmed it was exploited in the wild before patches were available, and CISA has already added it to its Known Exploited Vulnerabilities catalog.

What actually broke

The root cause is a classic and dangerous one: unsafe deserialization of untrusted data. When an application takes attacker-controlled input and turns it back into objects without properly validating it, an attacker can craft that input to make the application execute code it was never meant to run. In SharePoint's case, that means a remote attacker can inject and run arbitrary code on the server.

There's one important nuance worth flagging. The published CVE record describes the flaw as requiring no privileges, while Microsoft's separate exploitation narrative refers to an attacker authenticated as at least a Site Owner. Those two statements don't line up.

Why the urgency is real

This isn't a hypothetical waiting for a proof-of-concept. The timeline tells the story.

1. 2026/Jul/14

   Microsoft discloses CVE-2026-58644

   A critical RCE in on-premises SharePoint Server - and Microsoft confirms it had already been exploited in the wild. There was no patch-before-exploit window.

2. 2026/Jul/16

   CISA adds it to the KEV catalog

   The vulnerability lands on the Known Exploited Vulnerabilities catalog, with a remediation deadline of 19 July 2026 for U.S. federal civilian agencies.

A CISA KEV listing with a hard deadline is about as strong a "this is being used against real organisations" signal as you get. SharePoint has a long track record of being weaponised quickly after disclosure, and a pre-patch zero-day removes even the short grace period defenders usually get.

Are you affected?

The flaw affects supported on-premises SharePoint. Anything below the fixed builds should be treated as vulnerable.

To check your build, run this in the SharePoint Management Shell on your farm:

(Get-SPFarm).BuildVersion

Then confirm patch status in SharePoint Central Administration → Upgrade and Migration → Check product and patch installation status. Check every server in the farm - web front-end, application, search, standby, disaster recovery, and yes, test and non-production systems too. A single missed server keeps the door open.

Assume you may have been hit, and go looking

Because exploitation is confirmed, patching alone isn't enough - you need to check whether you were already compromised. Review IIS logs, SharePoint ULS logs, Windows Event Logs, authentication logs, and EDR telemetry for:

• Unexpected child processes spawned from IIS or SharePoint worker processes - PowerShell, cmd.exe, script hosts, or other admin tools.
• New or modified ASPX files, web.config files, scheduled tasks, services, or accounts - common persistence mechanisms.
• Credential access, encoded commands, lateral movement, or attempts to access or export IIS machine-key material.
• Web shells, malware, machine-key harvesting tools, or anomalous outbound connections from SharePoint servers.

One caution worth internalising: the absence of published indicators does not prove a system is clean. Detection guidance is still evolving, so keep checking the latest Microsoft and CISA advisories.

What an attacker can do once in

To be blunt about the blast radius, successful exploitation can lead to full compromise of the SharePoint server; access, modification, deletion or exfiltration of sensitive data; persistence through web shells and backdoors; theft of credentials, secrets, tokens, certificates and IIS machine keys; privilege escalation and lateral movement; and ultimately ransomware, service disruption and the regulatory, legal and reputational fallout that follows a breach.

The machine-key theft angle is what makes this more than a "patch and move on" situation - stolen keys can outlive the patch.

What to do - in priority order

1. Patch every farm server immediately

SharePoint updates are cumulative, so apply the latest July 2026 updates rather than stopping at the minimum fixed build.

• SharePoint Server Subscription Edition: KB5002882, build 16.0.19725.20434 or later.
• SharePoint Server 2019: KB5002883 plus language patch KB5002885, build 16.0.10417.20175 or later.
• SharePoint Enterprise Server 2016: KB5002891 plus language patch KB5002892, build 16.0.5561.1001 or later.

Critically: installing the binaries is not enough. Run the SharePoint Products Configuration Wizard (or the supported PSConfig process) on each server and verify the farm build and patch status. An update that hasn't completed the upgrade process doesn't protect you. With confirmed exploitation, treat this as an emergency change, not your normal patch cadence.

2. If compromise is suspected, treat it as an incident - not just a patch

Patching does not remove web shells, malware, persistence, or stolen secrets. If you find indicators:

• Isolate affected systems from untrusted networks and preserve forensic evidence before you start cleaning up.
• Scan for and remove intrusion artefacts - including machine-key harvesting tools - before rotating IIS machine keys.
• Rotate exposed secrets once you've contained and eradicated the threat: service-account credentials, privileged accounts, certificates, and tokens.
• Follow your incident-response process to scope the full extent of the compromise.

3. Harden to reduce future exposure

• Confirm AMSI (Antimalware Scan Interface) integration is enabled and working for each SharePoint web application, and keep antimalware and EDR coverage current.
• Get SharePoint off the open internet where it doesn't need to be public. Block external access to Central Administration and restrict admin access to trusted management paths.
• Limit farm and database traffic to the systems and ports that actually need it.
• Tune logging and alerting across SharePoint, IIS, Windows, identity, network, and EDR - and keep hunting after remediation, not just before it.

A confirmed zero-day in a system this deep inside the network isn't a "we'll patch it next cycle" problem. Patch every farm server and finish the upgrade, assume you may already be compromised and investigate, rotate machine keys and secrets if anything hits, and pull SharePoint back behind trusted networks.

- Staatse advisory desk, July 2026

The takeaway

CVE-2026-58644 checks the boxes that make a vulnerability a genuine emergency: critical severity, minimal barriers to exploitation, confirmed in-the-wild use before a patch existed, and a CISA deadline to match. The response is equally clear - patch every farm server and finish the upgrade, assume you may already be compromised and investigate accordingly, rotate machine keys and secrets if you find anything, and pull SharePoint back behind trusted networks.

With a confirmed zero-day, "we'll patch it next cycle" isn't a plan. Treat it as an incident until you've proven otherwise.

If you want help confirming whether your SharePoint estate was exposed - or hunting for a foothold if it was - our web application security testing and network penetration testing teams can scope an emergency review. Get in touch and we'll walk your team through it.