On July 19, 2025, Microsoft published the record for CVE-2025-53770 and stated that an exploit already existed in the wild. The vulnerability was marked as exploited and exploitation as detected. There was no prior public disclosure and no advance patch window; the flaw became public and known-exploited on the same day. That makes it the newest entry on this timeline and, in one respect, the hardest to write about responsibly—because the temptation with a live, actively exploited zero-day is to fill the gaps with drama the evidence does not support.
So this entry does two things at once. It explains what CVE-2025-53770, nicknamed ToolShell, actually was. And it treats the flaw as a case study in a discipline that runs through this whole timeline: how to report a live zero-day without turning uncertainty into a victim count.
CVE-2025-53770 is a deserialization-of-untrusted-data vulnerability (CWE-502) in on-premises Microsoft SharePoint Server. Its impact is unauthenticated remote code execution over the network, with a maximum severity of Critical. The CVSS score is 9.8 base and 9.3 temporal, with a vector describing network access, low attack complexity, no privileges required, no user interaction, unchanged scope and high impact to confidentiality, integrity and availability.
One boundary deserves to be stated plainly and up front, because it governs who was actually at risk: Microsoft 365 SharePoint Online was not vulnerable. This was an on-premises SharePoint Server flaw. Conflating the cloud service with the self-hosted product would have wrongly alarmed a very large population of users who were never exposed to it.
Serialization turns an in-memory object into a stream of bytes that can be stored or sent; deserialization reconstructs the object from those bytes. The danger is that reconstruction is not always a passive act of refilling fields—rebuilding certain objects can invoke code paths that have side effects. When untrusted, externally controlled serialized data reaches a deserialization routine that is capable of triggering such code paths, an attacker who shapes that data can steer the reconstruction toward executing code.
That is what happened here. SharePoint accepted serialized data and reconstructed objects on the server, and untrusted input was able to reach that path—allowing an unauthenticated network attacker to execute code. That is the correct level of detail to publish. Microsoft's record establishes the weakness category and the remote-code-execution result, but it does not provide enough information to describe the exact ToolShell request sequence. Respecting that limit is a choice, not an oversight: explaining the trust failure—externally controlled serialized state reaching a code-capable reconstruction routine—teaches the lesson without publishing a speculative or operational exploit recipe.
Microsoft said an exploit existed in the wild and marked exploitation as detected. Beyond that, the record does not identify a threat actor, a campaign, a malware family, a targeted sector or a victim count. That silence is data, and it should be preserved rather than filled.
The acknowledgements list khoadha of Viettel Cyber Security, and Viettel Cyber Security working with the Trend Zero Day Initiative. This is research credit for the discovery and disclosure work—it is not attribution of the attacks. Reporting that named these researchers as though they were the attackers, or that invented an actor to make the story feel complete, would misrepresent the source. The honest sentence is short: the flaw was exploited in the wild by a party the public record does not name.
The documented technical impact is precise: unauthenticated, network-based code execution against on-premises SharePoint Server. That is a serious impact on its own. What the record does not provide is any quantified number of affected deployments or confirmed compromises.
This is where the reporting discipline earns its keep. Scanner and exposure figures—counts of internet-visible SharePoint servers—circulate quickly during a live event, and it is tempting to present them as a damage total. They are not. Exposure measures how many systems could be reached, not how many were breached. With no victim total in the authoritative record, the correct thing to report is that no victim total was reported—and to resist the pull toward a bigger, rounder, more shareable number.
Standing up an isolated test farm to reproduce and study a SharePoint flaw means moving VM images and captures between machines quickly. The Samsung T7 Portable SSD is fast, portable storage for lab environments and forensic captures.
Amazon Affiliate Link
At initial disclosure, before every update was available, Microsoft offered two protective paths. The first was to enable SharePoint's AMSI integration and use Microsoft Defender across the SharePoint farm. The second, for environments where AMSI could not be enabled, was to remove the server's internet access. Either path was described as protecting against the unauthenticated attacks.
Security updates followed. The Subscription Edition and Server 2019 updates became available on July 20, 2025, and the Enterprise Server 2016 update was published in the security-update table. The fixed builds were:
| Product | Fixed build | KB |
|---|---|---|
| SharePoint Server Subscription Edition | 16.0.18526.20508 | — |
| SharePoint Server 2019 | 16.0.10417.20037 | KB5002754, KB5002753 |
| SharePoint Enterprise Server 2016 | 16.0.5513.1001 | KB5002760, KB5002759 |
The guidance was to install all applicable updates for whichever SharePoint software was present. Microsoft's record continued to be revised through August 6, 2025, with acknowledgements and informational changes rather than new technical claims.
ToolShell mattered technically as a maximum-severity, unauthenticated RCE in a widely deployed on-premises server, disclosed while it was already being exploited. But its lasting value on this timeline is methodological. It is a clean example of reporting a live zero-day accurately: state the confirmed impact, name the on-premises boundary that spared cloud users, credit the researchers without turning them into attackers, and refuse to convert exposure scans into a casualty figure.
That discipline extends to a related identifier. Microsoft noted that some new CVEs related to earlier SharePoint vulnerabilities—the CVE-2025-53770 update provides stronger protections than the earlier CVE-2025-49704 update, and the CVE-2025-53771 update provides stronger protections than the earlier CVE-2025-49706 update. That is the full supported extent of what the record says about CVE-2025-53771. It does not give that identifier a weakness class, an exploitation status or a CVSS score. So it should not be described as exploited, merged into ToolShell's mechanism, or treated as a second confirmed ToolShell zero-day. Where the record stops, the reporting stops too.