The patch that wasn't: why SharePoint's fix needed a fix

Patches are supposed to be the transaction that closes a vulnerability. CVE-2025-53770 is the latest evidence that the transaction keeps bouncing.

Microsoft shipped a fix for CVE-2025-49704 on July 8, 2025. On July 14, researchers at Code White GmbH reproduced a bypass against fully patched SharePoint servers. By July 18, Storm-2603 was deploying Warlock ransomware through the same endpoint. The July 8 patch blocked one attack vector and left a second one open on the same page, at the same URL, accepting the same POST parameter. Over 400 servers across more than 150 organizations were compromised, many through systems their administrators had already patched.

Unit 42 called it a “false sense of security.” That is precise language. It is also the whole problem.

What the patch missed

CVE-2025-49704 was a code injection flaw in /_layouts/15/ToolPane.aspx. The July 8 patch addressed that specific injection path. CVE-2025-53770, CVSS 9.8, exploits the same endpoint via .NET deserialization. An attacker sends a crafted serialized object in the MSOTlPn_Selected POST parameter, using known gadget chains like TextFormattingRunProperties or the PerformancePoint ExcelDataSet. SharePoint’s deserialization pipeline processes the object, and the attacker has code execution.

The two vulnerabilities share an endpoint, a parameter, and an authentication bypass (CVE-2025-53771, which mirrors the Referer-spoofing pattern from CVE-2025-49706). They differ only in the mechanism: code injection versus deserialization. The July 8 patch looked at what the attacker typed into the field. It did not look at what the field would do with a serialized object.

Microsoft’s emergency out-of-band patches on July 21 replaced the deserialization blocklist with a restrictive allowlist. That is the correct architectural fix. It is also the fix that should have shipped thirteen days earlier.

The pattern no one wants to name

This is not the first time a Microsoft patch has needed a patch.

PrintNightmare, 2021. CVE-2021-34527 was a remote code execution flaw in the Windows Print Spooler. Microsoft’s initial fix addressed the RCE vector but left the local privilege escalation path intact. Researchers bypassed the patch within days. Microsoft shipped a second fix. That one was bypassed too. The full remediation required disabling the Print Spooler service entirely on servers that did not need it, which is an operational workaround, not a patch.

ProxyShell and ProxyNotShell, 2021-2022. Exchange Server’s proxy layer was the target. Microsoft patched one SSRF chain (ProxyShell, CVE-2021-34473 and friends). Attackers found adjacent request paths. ProxyNotShell (CVE-2022-41040, CVE-2022-41082) used the same architectural surface with a slightly different entry point. Microsoft’s own URL-rewrite mitigation was bypassed before the patch shipped. The Exchange attack surface was not a single vulnerability; it was a category of vulnerability that Microsoft addressed one instance at a time.

ToolShell, 2025. Same pattern. The July 8 patch treated a specific code injection bug. The actual problem was that ToolPane.aspx accepted attacker-controlled input and processed it through multiple dangerous pipelines, only one of which got fixed.

The common thread is not that Microsoft ships bad patches. It is that the patches address the reported proof-of-concept rather than the attack surface. Fix the specific exploit. Ship it. Wait for someone to find the adjacent path. Fix that one too. The vulnerability is treated as a point. The attacker treats it as a surface.

What this costs defenders

The cost is not abstract. Between July 9 and July 21, every organization that applied the Patch Tuesday update for SharePoint was compliant with their patching SLA, compliant with CISA’s KEV directive for CVE-2025-49704, and exploitable. Talos reported that ToolShell-related incidents dominated their Q3 2025 engagement load.

CISA’s Binding Operational Directive 22-01 tracks whether an agency has applied a patch. It does not, and cannot, track whether the patch works. When Microsoft assigns a new CVE for the bypass, CISA adds it to KEV on July 20, and then imposes a 24-hour remediation deadline on July 22, the framework is functioning as designed. But functioning as designed still left a 12-day window where “patched” did not mean “protected.”

MachineKey rotation is the step that closes the ToolShell chain permanently, and it is the step that most patch-management runbooks do not include. The attacker’s first payload steals ASP.NET machine keys from web.config. Those keys remain valid after patching. An attacker who exfiltrated them during the gap window can forge ViewState blobs indefinitely. Rotating keys requires Update-SPMachineKey and an IIS restart, which means downtime, which means a change window, which means most organizations have not done it. Censys counted roughly 9,700 on-prem SharePoint servers internet-exposed as of mid-2025, and the number has not dropped significantly. MachineKey rotation compliance across that population is almost certainly well below 100%.

SharePoint Server 2016 and 2019 reach end-of-support on July 14, 2026. Storm-2603, the ransomware operator that exploited the ToolShell gap, pivoted to SmarterMail in February 2026. They are still active. The on-prem SharePoint attack surface is not shrinking fast enough.

What this actually means

Patch compliance is a necessary condition for security. It is not a sufficient one. That distinction matters because the entire compliance apparatus, from BOD 22-01 to vendor SLAs to audit checklists, measures the first condition and assumes the second.

When a patch is incomplete, the organization that applies it promptly is in a worse position than the organization that waits, because the prompt patcher believes the problem is solved. The slow patcher at least still considers themselves exposed. This is a perverse incentive that no framework currently addresses.

The fix is not to stop patching. The fix is to stop treating patches as the end of the process. For ToolShell, that meant rotating MachineKeys, hunting for web shells in the LAYOUTS directory, and checking IIS logs for the Referer-spoofing pattern, none of which appeared in the July 9 patch notes. Those steps were emergency additions after the bypass dropped. They should have been standard guidance from the start.

PatchDay Alert tracks these sequences, the initial patch, the bypass, the real fix, because the timeline between them is where organizations get hurt. A daily digest that tells you to patch is useful. One that tells you when patching wasn’t enough is the part that’s harder to find.

The July 8 SharePoint patch was not a failure of speed. It was a failure of scope. And scope failures do not show up in compliance dashboards until someone walks through the door they left open.