A patched SharePoint flaw was bypassed before every version got a fix

What happened

In July 2025, attackers exploited an on-premises Microsoft SharePoint Server flaw, tracked as CVE-2025-53770, before a complete fix existed for every supported version. CISA's alert, issued 20 July, describes the flaw as a bypass of an earlier patch for CVE-2025-49704 and points to scanning activity concentrated on 18 and 19 July. Microsoft's own customer guidance, published 19 July, confirms active attacks against SharePoint Server 2016, 2019 and Subscription Edition, states SharePoint Online is not affected, and instructs customers to apply new updates and, critically, rotate ASP.NET machine keys and restart IIS, since a stolen key can let an attacker forge trusted requests even after patching. A later Microsoft security blog names two China-based groups it tracks, Linen Typhoon and Violet Typhoon, as having exploited the flaws, and a third, Storm-2603, which Microsoft links only with moderate confidence to ransomware deployed from 18 July.

Confidence and limits

The vulnerability, its exploitation window and the machine-key remediation are corroborated by both the vendor and an independent government alert. The threat-actor names are Microsoft's own attribution, offered at two different confidence levels within Microsoft's own account; no court, government body or the affected customers have independently confirmed those attributions, and this record does not extend them further.

Why it mattered

The machine-key detail is the part worth understanding even without technical depth: patching the code path does not invalidate a key an attacker already stole through it, so a patched, unrotated server can remain silently accessible. That is why guidance from both the vendor and CISA insisted on key rotation as a distinct step from patching, not a formality after it. The flaw also mattered because it hit self-hosted infrastructure that many organisations run precisely to keep sensitive collaboration data off a vendor's cloud, undercutting the assumption that on-premises control is inherently safer.

Defensive takeaway

If you run on-premises SharePoint, confirm both the patch and a machine-key rotation have been applied, not just the patch, and check whether any end-of-support version is still reachable from the internet.

• Has your SharePoint deployment had its ASP.NET machine keys rotated since this patch, not only the software updated?
• Are any on-premises collaboration servers still reachable directly from the internet without a compensating control?
• Would your monitoring distinguish a forged authenticated request from a legitimate one if a key had already been stolen?

Exploitation here outran the normal patch cycle by design, targeting a bypass of an earlier fix rather than a fresh flaw. Treating machine-key rotation as inseparable from patching is the specific, checkable habit this incident leaves behind.