SharePoint's two-week window: patched servers were still exploitable

Organizations that applied the July 9 Patch Tuesday update to their SharePoint servers did everything their patch management process told them to do. They were still exploitable for two more weeks. Microsoft’s fix was incomplete, and the company knew it was incomplete only after three threat groups had already walked through the door. The emergency out-of-band patches didn’t ship until July 21. By then, 400 SharePoint servers across 150 organizations were compromised, and the ransom notes were already written.

The quiet part: Microsoft’s advisory for the real fix acknowledged “an exploitable deserialization path intact” in the first patch. That is vendor language for “we shipped it broken.”

The chain

The vulnerability chain, dubbed “ToolShell” by researchers, stacks three CVEs. CVE-2025-49706 bypasses SharePoint’s authentication by spoofing a Referer header pointing to the logout page. That gets an unauthenticated attacker to the vulnerable endpoint (/_layouts/15/ToolPane.aspx), where CVE-2025-49704 lets them inject .NET code that executes server-side. The first payload drops a web shell that steals ASP.NET machine keys from web.config. With those keys, attackers forge ViewState blobs that SharePoint’s deserialization pipeline trusts, achieving persistent RCE even after the original entry point is patched.

CVE-2025-53770 is the formal designation for the patch bypass. CVSS 9.8. A CVE for the fix not working. That’s the kind of thing that gets its own identifier now.

What it means for your environment

If you run SharePoint Online (Microsoft 365): nothing. This is exclusively an on-premises problem. SharePoint Enterprise Server 2016, 2019, and Subscription Edition are all affected.

If you run on-premises SharePoint and applied the July 9 update before July 21: you were still exploitable for two weeks, and you need to treat that window as a potential compromise period. The machine keys stolen during exploitation remain valid after patching. An attacker who exfiltrated them before you applied the emergency fix can still forge authenticated sessions until you rotate those keys. Patching alone does not close the door on someone who already copied the lock.

The blast radius was not theoretical. Storm-2603, a financially motivated group assessed as China-based, deployed Warlock ransomware starting July 18. Ransom demands were 0.005 BTC per victim. Two state-aligned groups, Linen Typhoon and Violet Typhoon, used the same chain for espionage across government, defense, healthcare, education, and telecommunications targets. By the time Microsoft published its disruption blog on July 22, Eye Security had found over 400 compromised systems and 8,000 SharePoint servers still internet-exposed.

CISA gave federal agencies a one-day remediation deadline. The standard KEV window is two weeks. When CISA compresses its own timeline by 93%, that tells you how the conversation went internally.

What you need to do

If you haven’t patched yet: Apply the emergency patches immediately. KB5002768 (Subscription Edition), KB5002754/KB5002753 (2019), KB5002760/KB5002759 (2016). Then rotate machine keys and restart IIS. If you cannot patch within hours, take the server offline or move it behind a VPN.

If you patched between July 9 and July 21: You need the emergency patches AND you need to assume potential compromise during the gap window. Rotate ASP.NET machine keys (ValidationKey and DecryptionKey) using Set-SPMachineKey, then iisreset.exe. Rotate service account credentials. Audit your LAYOUTS directories for unauthorized ASPX files, specifically spinstall0.aspx and variants.

If you’re running SharePoint 2013 or earlier: There is no patch. CISA’s guidance is to disconnect from the internet. Those versions hit end-of-support in April 2023.

Compromise checks for everyone:

• Look for POSTs to /_layouts/15/ToolPane.aspx with a /_layouts/SignOut.aspx referer in IIS logs
• Check for w3wp.exe spawning cmd.exe with Base64-encoded PowerShell
• Scan for C2 traffic to update.updatemicfosoft[.]com (note the typo, that’s the real C2 domain)
• Check Defender for Exploit:Script/SuspSignoutReq.A or Trojan:PowerShell/MachineKeyFinder.DA!amsi alerts

The structural problem

This is not a “patch when you can” situation. The combination of confirmed ransomware deployment, nation-state exploitation, and an incomplete first patch makes this one of the more operationally painful SharePoint vulnerabilities in recent memory.

The harder lesson is structural. Most patch-management runbooks assume that applying the vendor’s fix closes the exposure. They do not account for the vendor’s fix being wrong, or for the vulnerability stealing cryptographic material that persists independent of the bug itself. Key rotation is the missing step. Most orgs don’t have a runbook for it because most vulnerabilities don’t require it.

SharePoint 2016 and 2019 both reach end-of-support in July 2026. If you’re still running on-premises SharePoint exposed to the internet, Unit 42’s assessment is blunt: assume compromise. The migration conversation your org has been deferring just got more expensive to keep deferring.