Resources/Advisory

CVE-2025-53770: Microsoft SharePoint on-premises ViewState RCE (ToolShell)

An unauthenticated ViewState deserialization in on-premises SharePoint Server allows remote code execution as the IIS worker. Mass exploitation began before the out-of-band patch.

2025-07-216 min readSecureBlock research team

Microsoft published an out-of-band patch for CVE-2025-53770 on 20 July 2025 after Eye Security observed active exploitation against on-premises SharePoint Server. The chain, nicknamed ToolShell, combines a spoofing flaw (CVE-2025-49706) with a ViewState deserialization bug (CVE-2025-53770) to reach unauthenticated remote code execution as the IIS application pool identity. Multiple ransomware and espionage groups adopted it within 48 hours of disclosure.

What the flaw allows

The ToolPane.aspx endpoint accepts a __VIEWSTATE parameter that is deserialized without validation when the request originates from a spoofed internal source. An attacker forges the Referer header to bypass the source check, then supplies a ObjectDataProvider gadget in the ViewState blob to execute an arbitrary shell command.

http
POST /_layouts/15/ToolPane.aspx?DisplayMode=Edit HTTP/1.1
Host: sharepoint.example.com
Referer: /_layouts/SignOut.aspx
Content-Type: application/x-www-form-urlencoded

__VIEWSTATE=<base64 ObjectDataProvider gadget calling cmd.exe>

Minimal request shape. The spoofed Referer bypasses the origin check that was supposed to gate ToolPane.

The gadget executes as IIS APPPOOL\SharePoint and typical post-exploitation drops a spinstall0.aspx webshell in the SharePoint layouts directory. Eye Security also observed the attackers steal the ASP.NET MachineKey to sign their own ViewState payloads persistently, which survives the initial patch if you do not also rotate the key.

Who is affected

  • SharePoint Server Subscription Edition, 2019 and 2016 (on-premises)
  • SharePoint Online is not affected

The Internet-facing SharePoint farm is the primary target. Internal farms are exposed if an attacker has any foothold that can reach the SharePoint URL.

How to check exposure

Look for the known webshell in the layouts directory on every SharePoint server in the farm:

powershell
Get-ChildItem -Path 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\*\TEMPLATE\LAYOUTS' `
              -Recurse -Filter 'spinstall*.aspx' -ErrorAction SilentlyContinue

The spinstall0.aspx file is the confirmed post-exploitation artefact tracked by Microsoft.

Search IIS logs for the exploitation signature — POST requests to ToolPane.aspx with a SignOut.aspx referer:

sc-status: 200
cs-uri-stem: /_layouts/15/ToolPane.aspx
cs-uri-query: DisplayMode=Edit
cs(Referer): /_layouts/SignOut.aspx
cs-method: POST

Filter IIS logs for this combination; legitimate ToolPane usage does not carry the SignOut referer.

Check whether your MachineKey has been rotated since 20 July 2025. If it has not been rotated after applying the patch, treat it as compromised.

What to do

  • Apply the out-of-band security updates published by Microsoft on 20 and 22 July 2025 for each supported SharePoint version.
  • After patching, rotate the ASP.NET MachineKey on every affected web application and restart IIS across the farm. Patching alone is not enough if the key was stolen. Microsoft recommends the sequence:
powershell
Set-SPMachineKey -WebApplication <SPWebApplicationPipeBind>
Update-SPMachineKey -WebApplication <SPWebApplicationPipeBind>
iisreset.exe

Generate the new key, deploy it to the farm, then restart IIS on every SharePoint server. Rotate twice — once before and once after patching — to invalidate any stolen key material.

  • Assume compromise on any farm that had the vulnerable endpoint reachable from the Internet before the patch and had no restrictive WAF rule. Hunt for the webshell, unusual scheduled tasks, and outbound connections from the SharePoint service accounts.
  • Restrict access to _layouts/15/ToolPane.aspx at the reverse proxy or WAF to authenticated administrative source ranges until every farm server is patched:
# NGINX example: block ToolPane from the Internet
location ~* /_layouts/15/ToolPane\.aspx {
  allow 10.0.0.0/8;
  deny  all;
}

Blocking ToolPane at the proxy is a safe workaround; legitimate use is administrative.

Public tooling

  • Nuclei template — detection template landed in the ProjectDiscovery repository shortly after disclosure: http/cves/2025/CVE-2025-53770.yaml
bash
nuclei -id CVE-2025-53770 -u https://sharepoint.example.com

Nuclei detection run against a candidate SharePoint URL.

  • No Metasploit module was published in the framework at time of writing. Multiple standalone Python PoCs demonstrate the ToolPane referer bypass and ViewState gadget; a spinstall0.aspx webshell is the standard post-exploitation IoC to hunt for.

References

# Microsoft MSRC customer guidance
https://www.microsoft.com/en-us/msrc/blog/2025/07/customer-guidance-for-sharepoint-vulnerability-cve-2025-53770

# Fastly technical writeup
https://www.fastly.com/blog/toolshell-remote-code-execution-sharepoint-cve-2025-53770-cve-2025-53771

# Nuclei template
https://github.com/projectdiscovery/nuclei-templates/blob/main/http/cves/2025/CVE-2025-53770.yaml

Primary references.

Want this checked against your environment?