SharePoint's new RCE is live, and patching alone won't clean it

Microsoft shipped the fix on July 14. Two days later CISA added it to the Known Exploited Vulnerabilities catalog, and federal agencies have until July 19 to act. That compressed window is the tell. CVE-2026-58644 is the fourth on-premises SharePoint flaw pulled into the same wave of active exploitation this month, it ends in remote code execution, and researchers reported it was weaponized as a zero-day before the patch was available. The harder problem starts after you patch. Attackers hitting this cluster are stealing the server's cryptographic keys, and a stolen key does not care that you installed the update.

If you run SharePoint Server on your own hardware, treat this as an assume-breach event, not a routine Patch Tuesday line item. The editions in scope are the on-premises ones: Subscription Edition, Server 2019, and Server 2016. SharePoint Online is not affected.

What CVE-2026-58644 is, and who is exposed

The bug is a deserialization of untrusted data flaw (CWE-502) that Microsoft rates CVSS 9.8. A network attacker who reaches an authenticated context can write and run arbitrary code on the server. Microsoft's advisory says the attacker must already hold Site Owner rights or higher to pull it off. That reads like a barrier. It is a low one, and the reason matters enough to return to.

Patch each server to the build in the right column or later, then confirm the version number changed. Server 2016 goes to 16.0.5561.1001, Server 2019 to 16.0.10417.20175, and Subscription Edition to 16.0.19725.20434. Post-update verification carries more weight than usual here, for the persistence reason below.

"Authenticated" is doing less work than it looks

Site Owner is not a hard role to reach in a real SharePoint deployment. Many organizations delegate site collection administration widely, allow self-service site creation, and hand editor rights to contractors and line-of-business teams. One reused or phished credential can drop an attacker into that authenticated context. The access requirement filters out the fully anonymous internet and very little beyond it.

It thins further once you look at the other bugs Microsoft patched the same day. CVE-2026-56164, covered in our July Patch Tuesday writeup, is a missing-authentication flaw on the same SharePoint surface and is already on CISA's exploited list. CVE-2026-55040 is a weak-authentication bypass. An attacker who chains an authentication bypass into the deserialization bug needs no valid Site Owner login at all. Read on its own, CVE-2026-58644 understates the exposure. The cluster is the threat.

Why the patch is not the finish line

Here is the part the patch note does not spell out. CISA and Microsoft both report that post-exploitation on this cluster includes stealing the server's IIS machine keys. Those keys, the ValidationKey and DecryptionKey in machine.config, are what SharePoint uses to sign and encrypt __VIEWSTATE data. Once an attacker copies them, they can forge a signed __VIEWSTATE payload the server trusts and deserializes, which returns code execution. That capability outlives the update. You can patch CVE-2026-58644 to a clean build and still face an attacker who walks back in through the front door, because they hold a key you handed over before you patched.

This is why "we patched" and "we are clean" are two different statements this week. The same gap appeared on Ivanti Sentry, where the fix closed the entry point but did nothing about the foothold already inside. SharePoint's version is worse in one respect: the stolen artifact is a cryptographic secret, so eviction is not just deleting a web shell, it is rotating keys the intruder already read. A patch that cannot evict an intruder is a recurring shape in this year's exploited-flaw reports, and machine-key theft is the sharpest form of it.

Evict the intruder before you rotate the keys

Microsoft's guidance lists the steps, but the order is the whole game and it is easy to run backwards. The reflex after a key-theft advisory is to rotate machine keys first. Do not lead with that. If the attacker still has code execution on the box, rotating keys just lets them read the new ones, and if you rotate before removing a dropped web shell, the shell is still there. Sequence it: hunt and evict, then rotate, then validate.

• Patch and verify. Update every on-premises SharePoint server to the fixed build above, then confirm the build number actually changed.

• Turn on AMSI. Enable Antimalware Scan Interface integration and set the request-body scan to full mode, so deserialization payloads are inspected instead of trusted.

• Hunt before you rotate. Look for w3wp.exe spawning cmd.exe or powershell.exe, new or modified .aspx files under the SharePoint LAYOUTS and _app_bin directories, and unexpected edits to machine.config. File-integrity monitoring on the web root catches dropped files that a version check never will.

• Then rotate the machine keys once you are confident the host is clean, and treat any server you cannot clear as one to rebuild.

• Cut the internet exposure. Restrict direct inbound access and block external reach to SharePoint Central Administration.

On-premises SharePoint has now produced four exploited flaws in a single month, after Microsoft rated one of them "unlikely" to be hit right before CISA proved otherwise. That is not a run of bad luck. It is a signal about where attackers are spending their time. If you host it yourself, the posture that fits is continuous threat hunting on that server, not a patch cadence that assumes each fix is the end of the story.