DEV Community

Cyberoptic Security Ltd
Cyberoptic Security Ltd

Posted on

SharePoint “ToolShell” Vulnerability (CVE-2025-53770)

TL;DR

This is a critical SharePoint server bugthat lets attackers break in without authenticating and gain admin access to the system. This currently only affects SharePoint on-premise, and SharePoint online in M365 is not impacted.

In practice, an unauthenticated POST to the SharePoint ToolPane.aspx page (with a spoofed Referer header) bypasses login checks, allowing a malicious payload to run on the server.

Attackers can upload a web shell, extract the site's secret machine keys (ASP.NET ValidationKey/DecryptionKey), and use those keys to forge trusted ViewState or authentication tokens.

In short, they gain full access to SharePoint content (files, configs, internal APIs) and persistent control that survives normal fixes. The bug has been actively exploited in the wild, so urgent patching and follow-up are needed.

SharePoint is having a bad day

SharePoint is having a bad day

Exploit Chain

The "ToolShell" attack is an exploit chain combining two SharePoint flaws CVE-2025-53771/53770 into unauthenticated RCE. These were previously identified as CVE-2025-49706/49704 and patched however, bypasses for these have since been discovered. In simplified terms, attackers do the following:

  1. Authentication bypass via ToolPane.aspx: The attacker sends a specially crafted POST request to

/_layouts/15/ToolPane.aspx?DisplayMode=Edit 

with the HTTP Referer header set to /_layouts/SignOut.aspx. This tricks SharePoint into trusting the request without a real login. In effect, the attacker gains anonymous admin access to the ToolPane editor. (This bypass was patched as CVE-2025-53771.)

  1. RCE via insecure deserialization:With access to ToolPane.aspx, the attacker submits a malicious payload in the POST body. This payload uses an ASP.NET <asp:UpdateProgress> and a nested *Scorecard:ExcelDataSet*element whose *CompressedDataTable *attribute contains attacker-controlled data. SharePoint's Data Web Part (DWP) parser deserializes that *CompressedDataTable *on the server, triggering code execution. In practice this means the attacker can execute arbitrary PowerShell or other commands as the SharePoint process (w3wp.exe). For example, researchers observed the attacker's payload run *whoami *and write it to a web-accessible file to confirm code execution.

  2. Web shell and machine-key theft:The RCE allows the attacker to upload a web shell (commonly named spinstall0.aspx*or similar) into the SharePoint layouts folder. Using this shell or the existing context, the attacker reads the server's ASP.NET configuration (web.config), specifically the **section. The *ValidationKey *and *DecryptionKey *are used by ASP.NET to sign ViewState and encrypt auth tokens. The web shell code typically uses *System.Web's MachineKeySection to dump these keys to the attacker. With those keys known, the attacker has the server's cryptographic secrets.

  3. Persistence via forged ViewState/cookies:Armed with the stolen keys, the attacker can now forge valid ASP.NET payloads. They can craft a malicious __VIEWSTATE(or authentication cookie) and sign it so the server will accept it as legitimate. For example, tools like ysoserial.net can generate a new deserialization payload encoded into ViewState using the stolen ValidationKey. This grants the attacker essentially backdoor access, even if the original exploit is closed, the attacker can re-enter by sending new signed payloads that the patched server will trust. In effect, they maintain authenticated RCE without triggering logins or alerts.

  4. Post-exploitation and privilege escalation:Once code execution is achieved, attackers typically spawn a command shell on the host. In observed cases the SharePoint worker process (w3wp.exe) launches cmd.exe and then powershell.exe with encoded arguments to run their scripts. From this position, attackers can use Windows tools to gain higher privilege. For instance, they might use PsExec(with the -s option) or WMI tools (Impacket's wmiexec.py) to run processes as the LOCAL SYSTEM account. With SYSTEM-level code execution on the SharePoint server, attackers have full control: they can disable antivirus, dump AD credentials, or move laterally across the network. (Microsoft reports that after exploiting SharePoint, actors often use PsExec and Impacket/WMI to execute further commands as SYSTEM -- effectively a total takeover.)

How It Works "Under the Hood"

This exploit chain abuses normal ASP.NET mechanisms in unexpected ways:

  • ASP.NET ViewState:SharePoint pages use the __VIEWSTATE*hidden field to preserve state. By default, ASP.NET signs (and optionally encrypts) *ViewState with a MAC using the server's ValidationKey (from ). In normal use, this prevents tampering of page data. In ToolShell, the attacker injects a ViewState-like payload indirectly via the DWP (MSOTlPn_DWP) as described above. After stealing the keys, they can create entirely new ViewState blobs that the server will accept as valid.

  • ASP.NET machineKey:The *element in *web.config*defines two critical values: the *ValidationKey(for HMAC signing) and the DecryptionKey (for any encryption). ASP.NET uses these keys to

    (a) sign VIEWSTATE,

    (b) encrypt/decrypt FormsAuth or FedAuth cookies, and

    (c) protect any other secure state.

    When the attacker steals the keys, they can forge new authentication cookies (bypassing login) and viewstate, and even decrypt any data previously protected. For example, Cloudflare notes that with the machine keys an attacker "can independently forge authentication tokens and VIEWSTATE payloads" that survive normal mitigations. Simply rebooting the server or patching won't invalidate requests signed with the old key.

  • Data Web Part deserialization:SharePoint's ToolPane.aspx is meant for site admins to add/edit web parts. It processes a "Data Web Part" (DWP) specification from form data. The attacker abuses a legitimate PerformancePoint web control (Scorecard:ExcelDataSet) that has a property (CompressedDataTable) which ASP.NET deserializes directly. Hazcod's PoC explains that by setting *to base64-compressed XML, the SharePoint DWP parser will invoke .NET deserialization on it. In that payload, the attacker can embed a *System.DelegateSerializationHolder*or similar gadget that runs code. This is the core insecure deserialization: SharePoint never expected untrusted data here, and thus executes the serialized object unchecked. (The key form parameters are *MSOTlPn_Uri-- a fake control path -- and MSOTlPn_DWP -- the injected ASP.NET snippet.)

  • Referer check bypass: The authentication bypass itself was a patch bypass. SharePoint originally intended to block direct ToolPane access by checking the Referer header against legitimate pages. The exploit sends a Referer of /layouts/SignOut.aspx which, due to a logic bug, caused the check to succeed. In other words, SharePoint thought the user was signing out and then immediately editing ToolPane, and did not enforce login. Microsoft patched this logic, but attackers reversed it into the new CVE-53771 bypass.

Why It Remains Dangerous After Patching

If an attacker has already exploited the vulnerability before patching, the danger does not go away with a software update. This is because the attacker steals long-term secrets (the machine keys) during the attack. With those keys in hand, the attacker can forge new exploits or tokens at any time in the future, even after the CVE is patched. In short, the patch closes the vulnerability, but it does not change the stolen keys. Analysts warn that attackers "take the server's cryptographic machine keys" so they can persist beyond normal fixes. With the old keys, they can continue to generate authenticated ViewState payloads or cookies that the server will trust.

Put simply: a patched system that was already breached will still trust requests signed with the old ValidationKey/DecryptionKey. Rebooting or removing the web shell is not enough. Only rotating those keys, or completely rebuilding the server, can invalidate the attacker's hold. Until then, the attacker effectively has a master key to the server.

Mitigation and Hardening

Once patched, administrators must assume any exposed SharePoint system may have already been compromised. Below are the key steps needed to properly remediate and secure affected systems:

  1. ### Apply Microsoft's security updates

    Install the July 2025 cumulative updates for SharePoint:

    SharePoint Subscription Edition: KB5002768

    SharePoint Server 2019: KB5002754

    SharePoint Server 2016: KB5002760

These updates patch both CVE-2025-53770(RCE) and CVE-2025-53771(auth bypass), closing the main vulnerability chain exploited in the wild Microsoft Security Blog.

2. Enable AMSI and Defender

Microsoft recommends enabling AMSI (Antimalware Scan Interface) in SharePoint to inspect potentially malicious content. Ensure Microsoft Defender Antivirusis installed and active on the SharePoint server. This increases the chance of detecting web shells or suspicious ViewState payloads Microsoft Blog.

3. Rotate ASP.NET Machine Keys

The exploit allows attackers to steal the *section from *web.config, granting them the ability to forge authentication cookies or ViewState payloads. Simply patching will not revoke that access.

You must rotate these keys to invalidate any existing tokens. Microsoft recommends doing this via Central Admin:

Central Admin > Monitoring > Review job definitions > Run "Machine Key Rotation"

Then restart IIS (iisreset) to flush cached values Cloudflare, Microsoft Blog, and TrustedSec.

US-CERT and CISAexplicitly advise rotating the keys before and after applying updates.

4. Check for Signs of Compromise

Because attackers may already be inside the system, look for known indicators of compromise (IOCs):

  • Presence of suspicious files like:

    • /layouts/15/spinstall0.aspx(or variants: spinstall1.aspx, debug_dev.js)
    • Unusual scripts or executables in the SharePoint *LAYOUTS *folder

  • POST requests to /layouts/15/ToolPane.aspx?DisplayMode=Edit with odd Referer values

  • PowerShell execution or encoded command lines launched by w3wp.exe

  • Unexpected outbound connections or file writes from SharePoint directories

These indicators have been confirmed by Horizon3.ai, Cloudflare, and Hazcod's analysis. Also review Windows Event Logs and Defender logs for signs of tampering.

5. Invalidate All Authentication Tokens

Once the machine keys are rotated, all existing ViewState, FedAuth cookies, and FormsAuth tokens are invalidated. This ensures any attacker-forged tokens no longer work.

You should also:

  • Invalidate current user sessions

  • Require re-authentication for all users

  • Change credentials for any privileged SharePoint service accounts

  • Reboot the server after rotation to enforce the new keys Microsoft

6. Limit Exposure and Tighten Permissions

  • Remove internet exposure for outdated SharePoint versions (e.g. 2013 or earlier) as these are no longer supported NCSC NZ, CISA.

  • Apply the principle of least privilege to farm and service accounts.

  • Remove unnecessary admin users and test accounts from the SharePoint site.

  • Use firewall rules or a WAF to limit access to SharePoint's */layouts/15/ToolPane.aspx *endpoint where practical.

By combining the patch, detection, key rotation, IOC checking, and token invalidation, you significantly reduce the chance that attackers can maintain access using the stolen secrets. A reboot alone is not sufficient. These steps are consistent with best practice guidance from Microsoft, CISA, Cloudflare, VulnCheck, and NCSC NZ.

Official Security Advisories

Top comments (0)