ToolShell Exploits: Inside CVE-2025-53770 And CVE-2025-53771's Critical Threat To SharePoint

CVE-2025-53770 and CVE-2025-53771, collectively dubbed ToolShell, give attackers unauthenticated remote code execution and authentication bypass against on-premises Microsoft SharePoint. Both have been actively exploited, and both are patch bypasses — which means organisations that applied the previous fixes may still be exposed.

That last point is the one to take away. These are not isolated flaws; they are an evolution of CVE-2025-49704 and CVE-2025-49706, found by reverse-engineering the patches for them. Incomplete remediation produced a more effective attack chain than the original.

What ToolShell actually is

CVE-2025-53770 — the remote code execution

A severe RCE stemming from unsafe deserialisation of untrusted data, with a CVSS score of 9.8. It allows arbitrary code execution on a vulnerable server with no authentication at all. The flaw is in how SharePoint processes crafted HTTP requests aimed at the ToolPane.aspx endpoint: a manipulated request carries content that the server deserialises and executes, handing over full control. Outcomes range from complete system takeover to data exfiltration to ransomware deployment.

CVE-2025-53771 — the authentication bypass

The enabler. It lets an attacker reach SharePoint as an unauthenticated user, spoofing identity and evading controls that assume a request has been authenticated. Chained with the RCE above, it removes the need for credentials entirely — which is what turns a serious vulnerability into an internet-wide scanning opportunity.

Chained together, these two require nothing from the attacker but network reachability. No credentials, no user interaction, no phishing step.

Who is at risk

ToolShell affects on-premises SharePoint:

• SharePoint Server Subscription Edition
• SharePoint Server 2019
• SharePoint Server 2016
• SharePoint Server 2010 and 2013

SharePoint Online in Microsoft 365 is not affected. But a self-managed SharePoint instance is vulnerable wherever it runs — including on Azure, AWS or GCP. "It is in the cloud" is not the same as "it is SharePoint Online", and that distinction has caught people out.

How it is exploited

Observed campaigns follow a consistent chain.

Initial access

Reconnaissance to find reachable on-premises instances, then crafted HTTP POST requests to /_layouts/15/ToolPane.aspx. Those requests carry a forged Referer header — typically /_layouts/SignOut.aspx — which causes SharePoint to treat the payload as a legitimate authenticated request, exercising CVE-2025-53771.

Code execution

With authentication bypassed, the payload triggers the deserialisation flaw. It generally contains encoded PowerShell or a loader, and execution frequently occurs with high privilege — in some cases as NT AUTHORITY\SYSTEM. A web shell is commonly dropped, historically named spinstall0.aspx.

Post-exploitation

• Persistence via web shells, maintaining access after patching
• Data exfiltration — documents, configuration files, cryptographic secrets
• Credential harvesting, including MachineKey material
• Lateral movement, mapping Active Directory and expanding across the estate
• Ransomware deployment in some intrusions

Note the order. Patching after compromise closes the door on an attacker already inside — the web shell survives it. If you were exposed, patching is the beginning of the response, not the end of it.

Who is exploiting it

Per CISA and other vendors, ToolShell has been weaponised by nation-state actors including Linen Typhoon (China), Violet Typhoon (China) and Storm-2603, against finance, healthcare, education and energy.

What to do now

Apply Microsoft's emergency out-of-band updates immediately:

• SharePoint Server Subscription Edition — KB5002768
• SharePoint Server 2019 — KB5002754, and KB5002753 for the language pack
• SharePoint Server 2016 — KB5002760, and KB5002759 for the language pack

Then, because patching does not evict anyone already present:

• Rotate the ASP.NET MachineKey and restart IIS. Stolen key material lets an attacker forge payloads that survive the patch.
• Hunt for the web shells below, and for any unexpected .aspx in the SharePoint LAYOUTS directories.
• Review IIS logs for POST requests to ToolPane.aspx, especially with a SignOut.aspx referer.
• Check for the child processes that should never occur — w3wp.exe spawning PowerShell or cmd.
• Get it off the internet. An on-premises SharePoint reachable from anywhere is the precondition for all of this.

Indicators of compromise

Published by Microsoft for the ToolShell campaign. Defanged for safe handling.

Treat these as a starting point rather than a checklist. Hashes and infrastructure change; the behaviour described above does not.

The wake-up call

ToolShell is a vivid example of how incomplete patching and evolving tradecraft combine into a highly effective attack chain. Unauthenticated RCE against on-premises SharePoint is not a theoretical risk — it has been exploited by nation-state actors against critical sectors.

The lesson that outlasts these two CVEs is about patch bypasses generally. When a fix lands for something serious, a reasonable assumption is that somebody is already reverse-engineering it to find what the fix missed. That is an argument for monitoring behaviour as well as tracking versions — the next bypass will not have a CVE number attached to it on the day it is used against you.