ToolShell: unauthenticated ViewState deserialization RCE in on-prem SharePoint (CVE-2025-53770)

First, the scope, because it decides whether this is your problem at all. CVE-2025-53770 affects on-premises Microsoft SharePoint Server only. SharePoint Online in Microsoft 365 is not affected. The vulnerable products are SharePoint Server Subscription Edition on builds before 16.0.18526.20508, SharePoint Server 2019, and SharePoint Enterprise Server 2016 on builds before 16.0.5513.1001. If you run SharePoint on your own hardware or in your own cloud tenancy, and the front door answers from the internet, this dossier is about your server. If your users get SharePoint through the M365 portal, you can read this as a case study in why a patched CVE can still be a live incident. Verifiable security.

The mechanism: ViewState was never supposed to be attacker input

To understand ToolShell you have to understand what __VIEWSTATE is and the single assumption ASP.NET makes about it. ViewState is the mechanism ASP.NET Web Forms uses to persist the state of server controls across page requests. The server serializes control state into a Base64 blob, embeds it in a hidden form field named __VIEWSTATE, and the browser posts it back on the next request. When it comes back, the server deserializes it to rebuild the control tree. Deserialization of arbitrary .NET types is dangerous by construction, because the act of reconstructing certain objects runs code. That is CWE-502, Deserialization of Untrusted Data, and it is the same class that has produced RCE across the .NET and Java ecosystems for a decade.

ASP.NET is aware of this. Its defense is integrity, not sandboxing. Every ViewState blob is protected with the server's machine keys: a ValidationKey used to compute a message authentication code over the serialized state, and a DecryptionKey used to encrypt it. On the way back in, the server verifies the MAC before it deserializes. If the blob was not signed with the server's own ValidationKey, it is rejected and never reaches the deserializer. Under that model ViewState is safe, because an outsider cannot forge a valid signature without the key, and the key never leaves the server. The entire security of ViewState deserialization rests on two things holding true: the attacker cannot reach the deserializer with unsigned data, and the attacker does not know the machine key.

ToolShell breaks both. CVE-2025-53770 is a flaw in how the ToolPane.aspx layouts endpoint handles ViewState, such that attacker-controllable __VIEWSTATE data is deserialized without the validation that is supposed to gate it. Once the deserializer is reachable with untrusted bytes, a forged serialized .NET gadget chain, of exactly the kind tools like ysoserial.net produce, is reconstructed into a live object graph whose side effects run commands. No credentials are checked, no user interaction is needed, and the code runs with the privileges of the SharePoint and IIS worker process.

The auth bypass: a spoofed Referer to ToolPane.aspx

Reaching that endpoint pre-authentication is the other half of the exploit, and it is a separate primitive. In the wild, ToolShell is not one bug, it is a pair chained at runtime. The spoofing and authorization-bypass side is CVE-2025-49706, whose own bypass is tracked as CVE-2025-53771. The observed technique is disarmingly simple: an unauthenticated POST to /_layouts/15/ToolPane.aspx?DisplayMode=Edit carrying a spoofed Referer header, typically pointing at /_layouts/SignOut.aspx. That Referer value is enough to satisfy the flawed authorization check that was supposed to keep an anonymous request out of the tool pane. The request sails past the auth gate and lands on the vulnerable deserialization path, carrying the malicious ViewState in its body.

Put the two primitives together and you have the full ToolShell chain: the spoofed Referer gets an anonymous request to a privileged editing endpoint, and the ViewState flaw turns the body of that request into code execution. Neither half is enough alone. The auth bypass without the deserialization bug reaches a page it cannot exploit; the deserialization bug without the auth bypass sits behind a login. Chained, they are unauthenticated RCE on a trust anchor.

The real payload: stealing the machine key

Here is the part that separates ToolShell from a routine RCE and explains why responders kept finding compromised servers after they were patched. The first stage of the observed intrusions is not ransomware or a beacon. It is a small ASPX web shell, dropped under the SharePoint LAYOUTS directory, seen in the wild as spinstall0.aspx and close variants. That shell does one focused job: it reads the server's machine keys, the ValidationKey and DecryptionKey, and returns them to the attacker.

With those two values, the attacker no longer needs the vulnerability. Remember that the whole security model of ViewState is that only the server can produce a validly signed blob. Once the machine key is stolen, the attacker can produce validly signed blobs too. They can forge a __VIEWSTATE value carrying any gadget chain they like, sign it with the stolen ValidationKey, and the server will accept it as authentic and deserialize it, because from ASP.NET's point of view the signature is perfect. This is durable, unauthenticated RCE that survives patching. You can apply Microsoft's update, close the ToolPane deserialization path entirely, and the attacker still walks back in through the front door with a signed ViewState, because the trust relationship they exploited is your key, and your key has not changed.

The ToolShell chain, from anonymous request to key-backed persistence. Illustrative of the public record, not a runnable exploit.

The CVE lineage: from Pwn2Own demo to in-the-wild wormable pair

ToolShell has a paper trail worth reading, because it is a lesson in what an incomplete fix costs. The original deserialization RCE, CVE-2025-49704, and its paired auth bypass, CVE-2025-49706, were demonstrated together at Pwn2Own Berlin in 2025. Microsoft shipped fixes. The problem is that CVE-2025-53770 is a bypass of the incomplete fix for CVE-2025-49704, and CVE-2025-53771 is a bypass of the fix for CVE-2025-49706. In other words, both halves of the original pair were patched, both patches were sidestepped, and the sidestepped pair is what attackers turned on the internet at scale. It is the 53770 and 53771 combination that CISA added to the KEV catalog, because it is the one seen exploited in the wild rather than on a competition stage.

The uncomfortable takeaway is that the four CVEs are really two vulnerabilities that each got patched twice. When you read your remediation guidance, do not assume that having applied the earlier Pwn2Own-era fixes covers you. The whole reason 53770 exists is that the earlier fix was incomplete. Only the July 2025 out-of-band updates, applied per SKU, close the bypass.

Patch the code and the attacker is still inside, because the first thing they took was your key. ViewState trusts your signature. Once they can sign, they do not need the bug.

How to recognize your exposure

You can assess ToolShell risk without sending a single malicious request, because the exposure is decided by facts you can read.

1. Is it on-premises, and is it internet-facing? This is on-prem SharePoint Server only. Establish which of your SharePoint web front ends answer from outside the network, and whether the /_layouts/ paths are reachable anonymously. A purely internal farm carries a fraction of the risk of an exposed one.
2. What is the exact build number? Version is the highest-signal fact. Subscription Edition below 16.0.18526.20508 and Enterprise Server 2016 below 16.0.5513.1001 are in the vulnerable range, as is SharePoint Server 2019 before its July 2025 fix. The build number tells you whether the deserialization path is still open.
3. Have the machine keys been rotated since the patch? This is the question most inventories miss. Even a fully patched server is still exposed if the machine key was stolen before the patch landed and never rotated. Patch date without a key-rotation date is an open question, not a closed one.
4. What identity does the service run as? Code execution inherits the privilege of the SharePoint and IIS worker process. A high-privilege service account turns one request into high-privilege execution and easy lateral movement across the farm.

What to do about it

How Celvex catches this

ToolShell is a clean illustration of why patch status alone is a weak signal for trust anchors. The vulnerability lives in code, but the persistence lives in a key, and the two do not close on the same schedule. An organization that applied the July 2025 update the day it shipped can still be carrying an attacker who lifted the machine key the week before, and no amount of re-patching removes that access until the key is rotated. The discipline this rewards is the same one we apply everywhere untrusted input can reach an interpreter: know which of your trust anchors take outside input pre-authentication, on exactly which build, running as what identity, and, for this bug specifically, whether the secret that underwrites request integrity has been changed since the intrusion window.

Verifiable security. Find it. Prove it. Fix it. Verify the fix held, including the key rotation. That is what we ship.