It was late May in Berlin, during Pwn2Own: a Vietnamese security researcher unveiled a SharePoint exploit that combined authentication bypass with remote code execution.
Variants of these vulnerabilities fuel attacks today, attributed at least in part to Chinese actors. Targeting exclusively on-premises SharePoint servers, they are said to have affected about a hundred victims, including government organizations, mainly in Germany and the United States.
Initial fixes prove insufficient
The flaws revealed at Pwn2Own were assigned the identifiers CVE-2025-49704 and CVE-2025-49706.
The first lies in the .NET DataSetSurrogateSelector class. It opens the door to unreliable deserialization of inputs from a user authenticated at least as a SharePoint site owner.
The second provides a way to bypass authentication. It stems from a mismanagement of the HTTP Referer header supplied to the ToolPane endpoint. Hence the name given to the exploit: ToolShell.
On July 8, 2025, as part of its Patch Tuesday, Microsoft released patches for supported SharePoint Server versions (2016, 2019 and the Subscription Edition).
However, since then a more robust attack chain has emerged. It still relies on unsafe deserialization (CVE-2025-53770, with a higher base CVSS score). And it is paired with a directory traversal vulnerability (CVE-2025-53771) allowing impersonation of a server.
A technique seen before in 2021
This latter approach echoes CVE-2021-28474, which exploited an inconsistency in the server-side processing logic between input validation and security checks. Put simply, it was possible for SharePoint to execute malicious commands embedded in arbitrary ViewState objects that themselves were included in serialized requests.
At the time, the reach of the exploit was limited by the need to generate a valid signature for the objects. You needed access to the ValidationKey stored in the SharePoint server configuration. ToolShell, in its latest incarnation, enables the extraction of that key.
Beyond the patches Microsoft released on July 20, it is important to reset machine keys if automatic rotation is not enabled. This is a safeguard against any subsequent access.
Related cybersecurity stories
View all Cybersecurity articles
With CyberArk, Palo Alto targets a new acquisition in the […]
By
4 min.
AWS closes a software supply chain flaw […]
By
ToolShell: the situation one week after the patches
By
{ Expert Column } – The three levers of teams of […]
By
Between predictive and generative AI, cyber solutions balance
By