ToolShell: the mass SharePoint 0-day attack (2025)

In July 2025, administrators of on-premises Microsoft SharePoint servers lived through one of the worst weeks of the decade. A vulnerability tracked as CVE-2025-53770 — quickly dubbed “ToolShell” — allowed a SharePoint server to be taken over with no login at all, remotely, through a single HTTP request. Before Microsoft managed to ship a complete patch, attackers were mass-scanning the internet and planting web shells. It’s a textbook example of a “patched, but not really” vulnerability and of how fast an exploit can outrun the defence.

What ToolShell is and where it came from

The ToolShell chain debuted at the Pwn2Own Berlin contest in spring 2025, where researchers demonstrated a combination of two SharePoint bugs (CVE-2025-49704 and CVE-2025-49706) yielding remote code execution. Microsoft shipped patches in the July “Patch Tuesday” — but it turned out they could be bypassed. The bypass variants received new numbers: CVE-2025-53770 (RCE, CVSS 9.8) and CVE-2025-53771 (spoofing). And it was those bypasses that entered mass exploitation before an effective fix existed.

The mechanics are textbook: the attack exploited deserialisation and a forged Referer header pointing at the ToolPane.aspx endpoint to upload an ASPX file (a web shell) to the server. The crucial detail that made the attack so dangerous: attackers stole the server’s ASP.NET cryptographic keys (MachineKey). With those keys they could generate valid __VIEWSTATE tokens and return to the server even after it was patched — until the keys were rotated.

Scale: who got hit

Threat-monitoring firms counted dozens, then hundreds of compromised organisations worldwide — from public administration and universities, through energy companies, to the financial sector. The US CISA immediately added CVE-2025-53770 to its KEV (Known Exploited Vulnerabilities) catalogue. Both state-linked groups and ransomware operators joined the exploitation — a familiar pattern: a critical 0-day first serves espionage, then flows into ransom-driven crime.

An important caveat: this affected only on-premises SharePoint Server. SharePoint Online in Microsoft 365 was not vulnerable — another data point in the eternal debate about who patches: you or the cloud provider.

Lessons for defenders

ToolShell is a trove of lessons that reach far beyond one product:

A patch isn’t always the end. The bypass of the original fix shows that after a critical CVE you must track not just the bulletin but also reports of bypasses. Installing the July patch alone wasn’t enough — you had to apply a further one and, crucially, rotate the MachineKeys and restart IIS. Companies that merely “patched” were left with active attacker access.

Assume compromise, not just vulnerability. With a 0-day under mass exploitation, the question isn’t “are we vulnerable” but “have we already been taken over”. That calls for incident response: reviewing IIS logs for requests to ToolPane.aspx, hunting for unusual .aspx files in LAYOUTS directories, analysing for stolen keys.

Stolen secrets defeat patching. This is the key technical lesson: once an attacker exfiltrates keys, passwords or tokens, patching the flaw doesn’t remove them. After every serious breach, rotating secrets is as important as the patch — we covered this in the Salesforce OAuth token leak.

Internet-facing systems are the priority. SharePoint, VPN, mail servers — anything reachable from the network demands the shortest patch windows and the tightest monitoring. It’s the same pattern as CitrixBleed 2 or SAP NetWeaver the same year.

What to do if you run on-prem SharePoint

Even today, if you maintain local SharePoint: confirm that all patches from July 2025 and later are installed, rotate the MachineKeys and restart IIS, enable AMSI integration, then review logs retrospectively for traces from the exposure window. If the server was internet-facing during the critical window — treat it as an incident to investigate, not a closed matter.

Frequently asked questions (FAQ)

Was my company at risk if we use SharePoint in Microsoft 365? Not from ToolShell — only locally installed SharePoint Server was vulnerable. It’s a good illustration of the shared responsibility model: in the cloud, patching that layer is Microsoft’s job.

We patched in July 2025. Are we safe? Only if the patch covered the bypasses (CVE-2025-53770/53771) and you additionally rotated the MachineKeys. The original fix was bypassed, and without key rotation an attacker with earlier access could return despite the patch.

How do we check whether we’ve already been taken over? Review IIS logs for POSTs to ToolPane.aspx with a suspicious Referer, look for new .aspx files in the presentation-layer directories, and check for unusual w3wp.exe child processes. If in doubt — commission a forensic analysis.

What does ToolShell teach about patching in general? That the process doesn’t end at “patch installed”. After critical CVEs in internet-facing systems you have to track bypasses, rotate secrets and verify whether compromise has already occurred. It’s part of mature vulnerability management.

Would a pentest have caught this exposure? A regular external-infrastructure penetration test finds exposed, outdated services and assesses patch windows — exactly the conditions that turn 0-days into disasters. It won’t predict a specific 0-day, but it shows how large your attack surface is when one appears.

Summary

ToolShell (CVE-2025-53770) is a textbook example that in security what counts is not just “is it patched” but “how fast and how completely”. Mass exploitation started within days, the patch bypass made the first fix insufficient, and key theft made the attack immune to patching alone. If you run internet-facing systems and want to know how quickly you could respond to the next such scenario — let’s talk about testing and monitoring.

---

Sources and further reading: Microsoft MSRC, CISA KEV.