Microsoft SharePoint — ToolShell zero-days

Two chained zero-days in on-premises SharePoint enabled unauthenticated remote code execution; incomplete patches kept attackers in for months.

Target: Microsoft SharePoint — ToolShell zero-days
Date public: 19 July 2025
Sector: Technology
Attack type: Vulnerability Exploit
Threat actor: Linen Typhoon, Violet Typhoon, Storm-2603 and others (China-linked)
Severity: High
Region: Global

// In plain English

Microsoft SharePoint is the file-sharing and collaboration platform that hundreds of thousands of organisations run on their own servers. In mid-2025 several Chinese state-linked groups discovered four chained bugs that gave them the ability to take over any internet-facing SharePoint server with no credentials required. Microsoft's first patch didn't fully fix the problem, so attackers retained access for months. By the time the dust settled, tens of thousands of corporate file servers worldwide had been compromised — exposing internal documents, credentials and email metadata. The episode became the canonical example of why patching is harder than it looks: even a vendor's first patch isn't always enough.

What happened

In mid-July 2025, security researchers and several major incident-response firms began seeing the same pattern across customers running on-premises Microsoft SharePoint Server: webshells appearing on internet-facing SharePoint endpoints, persisted via a path that bypassed the patches Microsoft had shipped earlier the same month. The chain became known as ToolShell.

The story has four CVEs and two phases. In May and early June 2025, researchers reported a SharePoint authentication bypass (CVE-2025-49706) and a deserialisation flaw enabling remote code execution (CVE-2025-49704). Microsoft patched both in the July 2025 Patch Tuesday cycle. Within days of the patches landing, the Dutch firm Eye Security observed mass exploitation of what looked like the same vulnerabilities — except the patched servers were also being compromised. Microsoft confirmed that two new CVEs (CVE-2025-53770 and CVE-2025-53771) were patch bypasses for the original pair: minor variations in the request structure that defeated the July fix.

By the time CISA issued its emergency directive and Microsoft shipped a complete fix late in July, hundreds of SharePoint Servers had been compromised — Eye Security counted 396 confirmed at one snapshot — across government bodies, healthcare providers, education institutions, and corporate environments globally. The Microsoft Threat Intelligence Center attributed the bulk of the activity to three China-linked clusters: Linen Typhoon, Violet Typhoon, and Storm-2603. ToolShell was not the only threat actor in the SharePoint estate; the vulnerability was sufficiently lucrative that several criminal and access-broker operations were observed using it in parallel.

How it worked

The ToolShell chain has two essential moving parts. First, the authentication bypass: a crafted request to the SharePoint ToolPane.aspx endpoint, with a specific Referer header value, persuades the server to treat the request as authenticated when it is not. Second, the deserialisation gadget: the bypass routes into a SharePoint code path that deserialises an attacker-supplied payload, executing arbitrary code in the context of the SharePoint application pool — typically a service account with substantial local privileges.

What made ToolShell particularly damaging was the post-exploitation pattern. The attackers consistently moved to extract the SharePoint server’s ASP.NET machine keys — the cryptographic material SharePoint uses to sign and validate viewstate data. With the machine keys in hand, the attackers could forge valid __VIEWSTATE payloads from any SharePoint instance configured with those keys, including instances that were patched after the initial compromise. In other words: patching a SharePoint Server that had already been compromised did not evict the attacker, because the attacker could continue authenticating using stolen cryptographic material. The complete recovery procedure required rotating the machine keys, not just applying the patch.

The incomplete July patch is the second element worth dwelling on. Patches for deserialisation vulnerabilities are notoriously difficult to get right because they typically block specific exploitation gadgets rather than fixing the underlying class of issue. Microsoft’s initial patches addressed the proof-of-concept request signatures in circulation in early July. Within days, attackers — and almost certainly some defensive researchers in parallel — found request shapes that triggered the same code path without matching the patched signatures. This is a recurring pattern in deserialisation-class vulnerabilities and one of the reasons CISA’s guidance increasingly emphasises restricting internet exposure of legacy enterprise applications rather than relying on patches alone.

Timeline

May 2025 — CVE-2025-49706 (SharePoint authentication bypass) and CVE-2025-49704 (deserialisation RCE) responsibly disclosed to Microsoft.
8 July 2025 — Microsoft ships the July 2025 Patch Tuesday including fixes for both CVEs.
18–19 July 2025 — Eye Security observes patched SharePoint Servers being compromised; coordinates with Microsoft on patch-bypass evidence.
20 July 2025 — CVE-2025-53770 and CVE-2025-53771 assigned; CISA adds the SharePoint chain to the Known Exploited Vulnerabilities catalogue.
22 July 2025 — Microsoft ships out-of-band complete fix; CISA issues emergency directive ED 25-04 for federal civilian agencies.
Late July 2025 — Microsoft Threat Intelligence Center publishes attribution to Linen Typhoon, Violet Typhoon and Storm-2603.
August–November 2025 — Sustained exploitation of unpatched and incompletely-remediated SharePoint estates; CISA reissues guidance twice.
Early 2026 — ToolShell-related compromises continue to appear in incident reports as organisations discover stolen machine keys still in use.

What defenders should learn

The headline operational lesson is awkward but consistent with the trajectory of the past several years: any internet-facing on-premises SharePoint Server is, in 2026, a load-bearing security decision that needs an explicit owner. The maintenance burden of legacy enterprise applications continues to rise faster than most organisations’ patching cadence. SharePoint is in that category alongside Exchange, Confluence, Citrix and the rest of the long tail of pre-cloud-era enterprise software with internet-exposed administrative surfaces.

The deeper lesson is about cryptographic material as a persistence mechanism. ToolShell is one of a growing number of exploit chains where the post-compromise objective is not a webshell or a backdoor but a piece of long-lived authentication material — machine keys, session signing secrets, OAuth refresh tokens, Active Directory Federation Services certificates. Once that material is stolen, patching the original vulnerability does not restore the security boundary. The patched system continues to honour requests authenticated with the stolen material until the material is rotated.

For organisations thinking about how to constrain the blast radius of an internet-facing application compromise, ToolShell is a clean example of why network and identity boundaries need to be treated as a single design problem. Andy will layer the segmentation lens in more thoroughly when he has time; the bare operational observation is enough to act on.

Controls that would have helped

Defender controls catalogued in the Controls Desk that would have changed the outcome of this incident, or limited its blast radius. Sourced from regulator and framework guidance — never vendors.

Patching · ease 3/5 · impact 5/5 Patch internet-facing services within 14 days of disclosure Every system that answers an unsolicited connection from the internet is patched inside fourteen days of vendor disclosure. The clock starts at disclosure, not at scheduled change window.

Sources

Back to all incidents