ToolShell: Critical SharePoint RCE Explained

What is it?

ToolShell refers to a set of closely related vulnerabilities in on-prem Microsoft SharePoint—first disclosed as CVE-2025-49704 and CVE-2025-49706, and more recently tracked as variants CVE-2025-53770 and CVE-2025-53771. These flaws can allow an unauthenticated attacker to jump straight from the internet to arbitrary code execution on the server. First revealed at Pwn2Own Berlin in May 2025 and now under active attack worldwide, ToolShell has forced Microsoft, CISA, and multiple security vendors to issue emergency guidance and patches.

Note: If you’ve been following the technical details of the ToolShell exploit, you may have seen differing interpretations of how CVE-2025-53770 and CVE-2025-53771 work. See the appendix for a closer look at the advisories and what’s being exploited.

What can attackers do?

Once an attacker achieves full compromise of a vulnerable SharePoint server, they can pursue several high-impact outcomes:

• Impersonate Users: Malicious actors can execute actions as legitimate users (including admins), bypassing permission controls and disabling detection while corrupting audit trails.

• Expose Secrets: Attackers can locate and extract sensitive information (API keys, credentials, tokens) from SharePoint docs or configuration elements, then pivot into other systems undetected, compromising CI/CD, APIs, or internal services.
• Maintain Access: Lateral movement techniques allow attackers to drop web shells or manipulate serialized state data (e.g., __VIEWSTATE), ensuring persistent backdoors remain after patching, IIS restarts, or shell cleanup.

• Access Services: Cryptographic keys (such as machineKey.validationKey) can be extracted and reused to sign data or tokens, enabling attackers to bypass authentication and interact with internal services directly.

Is it actively exploited?

Yes, Microsoft has confirmed active exploitation.

Microsoft is aware of active attacks targeting on-premises SharePoint Server customers by exploiting vulnerabilities partially addressed by the July Security Update.

– Microsoft Security Response Center

Is it easy to exploit?

Yes, detailed exploitation analysis and PoC scripts have been publicly available since July 21, 2025.

Am I Impacted?

All of these vulnerabilities affect SharePoint Enterprise Server 2016 and 2019.

CVE-2025-49706 and CVE-2025-53770 also impact SharePoint Server Subscription Edition.

SharePoint Online in Microsoft 365 is not affected.

How does the exploit work?

The attacker first skips authentication altogether by sending a crafted POST request whose Referer points to /_layouts/SignOut.aspx to bypass authentication. With edit-mode rights, they upload a malicious Web Part whose <Scorecard:ExcelDataSet> element embeds a Base64-encoded and gzip-compressed, serialized .NET payload in the CompressedDataTable attribute.

When SharePoint attempts to render this Web Part, the payload is insecurely deserialized, giving the attacker code-execution on the server. They drop an ASPX web-shell, dump the site’s machineKey.validationKey, and use it to sign arbitrary __VIEWSTATE data—letting them regain code-execution even after the shell is removed and patches are applied.

Exploit Timeline

In early May, researchers unveiled the “ToolShell” SharePoint exploit chain (CVE-2025-49704/49706) at Pwn2Own Berlin. Microsoft released fixes on 9 July, but five days later CODE WHITE publicly reproduced the chain, and by 18 July Eye Security was seeing it used in the wild. As variants surfaced (CVE-2025-53770/53771), Microsoft published advisories on 20 July; that same day CISA put both CVEs in its KEV list and Microsoft pushed patches for SharePoint 2019. A day later, hotfixes for SharePoint 2016 followed, and on 22 July Microsoft attributed the active campaigns to Chinese state-aligned actors.

Conclusion

ToolShell represents a critical threat to on-premises SharePoint environments, involving CVE-2025-53770 and CVE-2025-53771 in exploits that enable unauthenticated remote code execution. With active worldwide exploitation and publicly available proof-of-concept code, organizations running SharePoint 2010 through Subscription Edition face immediate risk.

Trickest enables security teams to proactively detect and respond to critical threats like ToolShell through automated reconnaissance, custom detection workflows, and integration with live attack surface data.

Contact us to secure your SharePoint infrastructure

Appendix: Clarifying CVE-2025-53770 vs. 53771.

What’s Actually Being Exploited?

There has been a lot of fast-moving information around the ToolShell exploit and its related CVEs. As with any active exploitation event, interpretations can evolve quickly. We want to take a moment to explore some of the reporting and add helpful context where we think some confusion may have crept in.

What's being said

Some coverage — including from Wiz and blogs that echoed it — describes the current ToolShell attacks as a chain of two CVEs:

• CVE-2025-53771: An authentication bypass via a spoofed Referer header

• CVE-2025-53770: An insecure deserialization RCE, requiring the above bypass to be exploitable

This mirrors the original Pwn2Own chain (CVE-2025-49704 + 49706), where exploiting the RCE required elevated privileges.

From Wiz’s blog post:

• Initial Entry (CVE-2025-53771): The attacker sends a POST request to /_layouts/15/ToolPane.aspx?DisplayMode=Edit using a crafted Referer header (/_layouts/SignOut.aspx) to bypass authentication. This leverages a header spoofing vulnerability that makes SharePoint treat the request as authenticated.
• Payload Delivery (CVE-2025-53770): With authenticated access to the vulnerable ToolPane.aspx endpoint, the attacker exploits an insecure deserialization vulnerability by submitting a malicious payload in the POST body.

This interpretation hinges on the idea that 53770 requires authentication, and 53771 removes that requirement. But do the advisories support that claim?

What do the advisories say?

CVE-2025-53770 is described by Microsoft as an unauthenticated remote code execution vulnerability caused by unsafe deserialization.

"Deserialization of untrusted data in on-premises Microsoft SharePoint Server allows an unauthorized attacker to execute code over a network."

It has been added to CISA’s Known Exploited Vulnerabilities (KEV) catalog and marked as Exploited: Yes and Privileges Required: None in Microsoft’s advisory.

This strongly suggests that CVE-2025-53770 does not require authentication, and therefore likely doesn’t need to be chained with a separate auth bypass (like CVE-2025-53771) to be exploited.

CVE-2025-53771 is described in Microsoft’s advisory as an improper authentication issue involving a path traversal tactic. However, none of the public exploit details or PoCs observed so far appear to use a path traversal.

Additionally, the advisory marks it as Exploited: No and it has not been added to CISA’s KEV catalog; another indication that 53771 may not be part of the exploit currently seen in the wild. Instead, it may represent a separate vulnerability or a defense-in-depth fix addressing other potential vectors not yet publicly disclosed.

What Eye Security actually said

The original Eye Security report was clear in labeling the original ToolShell (CVE-2025-49704 + CVE-2025-49706) as a chain, but did not describe the 53770 exploit as a chain.

In fact, they wrote:

We believe that this Referer might made CVE-2025-49706 into a 0-day, later named by Microsoft as CVE-2025-53770.

This seems to suggest that the Referer bypass may be baked into 53770 itself, not a separate 53771 chain component.

So what’s our current understanding?

It’s still possible more details will come to light, but based on what's currently public:

• CVE-2025-53770 appears to be a standalone unauthenticated RCE.

• The original ToolShell (CVE-2025-49704 + CVE-2025-49706) is a chain, combining a Privilege Required: Low RCE with an authentication bypass.

• CVE-2025-53771 may be unrelated to the current attacks, and possibly a separate class of path traversal or future bypass hardening.

We’re piecing this together like everyone else and welcome any corrections or new insights. If we learn more, we’ll update the post accordingly. For now, we hope this helps clear up some of the confusion for security teams.