Patched. KEV-compliant. Still exploitable.

The July 8 patch was on time. It was complete with respect to the bug Microsoft was told about. It was incomplete with respect to the endpoint the bug lived in. Six days later a researcher demonstrated a bypass. Eleven days later Storm-2603 was deploying ransomware through it. The operators who patched fastest were not, in this window, the safest operators. They were exploited at the same rate as everyone else, with the additional cost that their compliance dashboards turned green while it was happening.

CVE-2025-49704 and CVE-2025-53770 reach the same URL, accept the same POST parameter, and bypass authentication through the same Referer spoof. They differ in what they do with the field’s contents. The July patch sanitized one mechanism — code injection through the field — and left a second mechanism — .NET deserialization of the same field — open to the same caller. The July 21 out-of-band update did the structurally correct thing and replaced the deserialization blocklist with an allowlist. The thirteen days between the two patches is the window that matters: it is the window in which “patched” and “protected” diverged for every on-prem SharePoint operator in the world.

The vault-style gap that follows the patch is the part the advisory does not direct. The first payload through CVE-2025-53770 lifts the ASP.NET MachineKey values from web.config on the way to dropping a webshell. Those keys remain valid after the July 21 patch ships and after the webshell is removed. An attacker with the keys can forge ViewState blobs against the farm indefinitely; rotating them requires Update-SPMachineKey and an IIS restart, which is a planned outage on most change boards. The KB articles describe the patch. They do not direct rotation. Most patch-management runbooks therefore do not include it. Three quarters of the on-prem SharePoint fleet that was internet-reachable in July 2025 is still internet-reachable today, and an unknown but probably large fraction of those farms have not rotated their keys.

The compliance dimension is the part that does not fix itself by shipping a better patch next time. BOD 22-01 measures patch application. It cannot measure patch completeness. The July 8 patch closed a CVE; the July 21 patch closed a different CVE on the same endpoint family. Both can pass an audit. The operator-facing version of the question is whether the farm was reachable between July 8 and the date the July 21 update was actually installed (which for a non-trivial number of operators is some weeks later than July 21), and whether MachineKey rotation has been performed since. The auditor’s-version of the same question is whether the control narrative for SharePoint patching accounts for the difference. Most do not.

The narrow lesson is product-specific: the post-patch checklist for ToolShell is not the patch. It is the patch, the AMSI integration, the MachineKey rotation, the webshell hunt under _layouts/, and the IIS log review for the Referer-spoofing pattern. The wider one is that “fixes the reported PoC” is the floor, not the ceiling. An endpoint that processes attacker-controlled input through a deserialization pipeline can be patched against one gadget chain and remain exposed to the next, on the same parameter, on the same URL, without anyone in the patch-notes chain noticing.