SharePoint 'ToolShell': insecure deserialization to unauthenticated RCE and key theft

What happened

Microsoft SharePoint Server is a widely deployed on-premises collaboration and document platform, often internet-exposed. On July 19, 2025, Microsoft disclosed CVE-2025-53770, an insecure-deserialization vulnerability carrying a CVSS score of 9.8. It had already been exploited in the wild as a zero-day by an unknown threat actor before the advisory. The exploit chain — nicknamed "ToolShell," after a technique demonstrated at Pwn2Own Berlin 2025 — gives an unauthenticated attacker remote code execution. Affected products span SharePoint Subscription Edition, 2019, and 2016.

The most damaging step comes after initial access: attackers deploy a webshell and extract the server's ValidationKey and DecryptionKey. With those machine keys in hand, they can forge signed authentication tokens at will — persistence that survives patching of the original bug. The CVE was itself a patch bypass of the earlier CVE-2025-49704.

Root cause

SharePoint deserialized attacker-controlled data without validating its integrity — CWE-502, insecure deserialization, the heart of OWASP's Software and Data Integrity Failures category. A crafted serialized payload was reconstructed into live objects that drove code execution. Because the theft of static machine keys followed, the failure to protect and rotate those secrets turned a code-execution bug into durable, credential-forging access.

How it would have been caught

Deserialization sinks are detectable statically (CodeQL/Semgrep rules for unsafe BinaryFormatter/type resolvers) and dynamically by firing known gadget-chain payloads at the endpoint. A reproduction posts the malicious serialized blob and confirms it executes code or lets the server reconstruct an attacker-chosen type, rather than rejecting untrusted input.

How to prevent it

• Do not deserialize untrusted data; if unavoidable, bind to explicit allow-listed types and verify integrity (signing) before deserializing.
• Protect and rotate machine keys after any suspected compromise — stolen keys outlive the patch.
• Patch on disclosure and verify the patch actually closes the path, since this CVE bypassed an earlier fix.

The Breachwire test (red → green)

Post the gadget-chain payload and confirm it deserializes into code execution — the RED control. Restrict deserialization to allow-listed types with integrity checks, then confirm the same payload is refused while legitimate requests still process. Rotate the ValidationKey/DecryptionKey and confirm previously forged tokens no longer validate.