ToolShell and Warlock: why a supply-chain attack on on-prem SharePoint hit 400+ servers across 148 organizations — and what it means for your business?
BLUF
In July 2025 China-linked actors (Linen Typhoon, Violet Typhoon and Storm-2603) exploited a two-bug zero-day chain in on-prem Microsoft SharePoint Server — CVE-2025-53770 (unauthenticated RCE + auth bypass) and CVE-2025-53771 (spoofing). Storm-2603 deployed Warlock ransomware on 400+ servers across 148 organizations — government, education, healthcare, including US federal agencies and a nuclear agency. The attack required no credentials and bypassed MFA. Microsoft released an emergency patch and CISA added the flaw to its KEV catalog. Takeaway for B2B/manufacturing: on-prem SharePoint is a real supply-chain attack surface — it demands urgent patching, asset inventory and business-continuity planning.
Key facts
- A two-bug zero-day chain in on-prem Microsoft SharePoint Server — CVE-2025-53770 (unauthenticated remote code execution via deserialization at the ToolPane.aspx endpoint, with authentication bypass) plus CVE-2025-53771 (server spoofing) — was actively exploited from around July 7, 2025, well before public reports on July 18. [1][4][5]
- Storm-2603 (China-linked, moderate confidence) deployed Warlock ransomware on over 400 SharePoint servers across 148 organizations — including government, education and healthcare; victims span US federal agencies (DHS, NNSA/DOE, Department of Education, NIH) and Western government agencies. [1][2]
- Eye Security scanned 23,000+ SharePoint servers and confirmed at least 400 compromised across four attack waves (July 17, 18, 19 and 21, 2025). [1]
- The attack required no credentials or user interaction — unauthenticated RCE with MFA and SSO bypass; it affected only on-prem installations (SharePoint Online cloud was not vulnerable). [2][4]
- Microsoft released an emergency patch (outside Patch Tuesday), and CISA added CVE-2025-53770 to its KEV catalog, ordering US federal agencies to patch within a day — underscoring how serious the active exploitation was. [1][3][5]
Decision table
| Area | What we know | What it means for B2B/manufacturing | Recommended action (30/90 days) |
|---|---|---|---|
| On-prem SharePoint / web apps | Unauthenticated zero-day RCE, active exploitation | Internal SharePoint, portals and ASP.NET apps are a real initial-access vector in the supply chain | Urgent inventory of exposed web services; deploy MS patches + rotate ASP.NET MachineKey after compromise |
| Authentication / remote access | Exploit bypasses auth, MFA and SSO | MFA does not protect against this class — patching and segmentation, not just auth, matter | Network segmentation, reduce web-service exposure, verify the patch is actually deployed |
| Supply chain and vendors | APT groups exploit widely used software (SharePoint) | A vulnerable vendor component can open the whole environment | Map dependencies on on-prem software; require patching in vendor contracts |
| Business continuity / BCP-DR | Warlock ransomware encrypts servers, risk of downtime | Loss of SharePoint/portals halts business processes and documentation | Tested backups, recovery plan, ransomware scenarios |
| NIS2/KSC obligations (Art. 21/23) | Incident illustrates vulnerability management, supply chain and incident reporting | Obligation of due technical measures and reporting of significant incidents | Organized patch-management process + vulnerability register; prepare incident reporting |
Marcin Białczyk's perspective
In operational practice this incident shows two problems I keep seeing in manufacturing and B2B companies. First — on-prem SharePoint and other internal web servers are treated as "quiet infrastructure", yet they are often the largest supply-chain attack surface. When software used by hundreds of organizations gets an unauthenticated zero-day, your firewall quality does not matter — what matters is whether you can patch and isolate the vulnerable component fast. This is the vulnerability-management lesson I repeat to clients: it is not "how many patches do we have today", but how quickly we can respond to a zero-day in a component many people do not even remember exists.
Second — MFA and strong passwords are not the defense here. This exploit bypassed authentication and MFA entirely. So from an operational standpoint I cannot imagine a secure environment without two foundations: (1) an up-to-date inventory of web services and vulnerability management with a clear owner, and (2) tested continuity scenarios for a ransomware event. These are exactly the areas that NIS2/KSC (Art. 21) treats as an obligation of due care — and that in practice determine the scale of damage.
[[TO ADD — production client case study (patching on-prem SharePoint/web portals, MachineKey rotation, segmentation) when such a case exists; no fictional scenarios.]]
FAQ
Is my company at risk if we do not use SharePoint?
Indirectly, yes. This attack class shows that widely used on-prem software (SharePoint, portals, ASP.NET apps) can be hit by unauthenticated zero-days. If you run any internal web service or vendor application, you have a similar attack surface and need patching and inventory processes.
Will MFA protect us from an attack like this?
Not in this case. CVE-2025-53770 allowed unauthenticated remote code execution and bypassed MFA and SSO. MFA protects against credential theft, not against flaws in the software itself — so patching and segmentation are key.
How fast must I react to a similar zero-day?
CISA required US federal agencies to patch within one day of the KEV entry. For commercial organizations we recommend deploying the fix within a few days, and immediately (emergency mode) for exposed web services, including key rotation (e.g., ASP.NET MachineKey) after a confirmed compromise.
Is SharePoint cloud safe?
The attack targeted on-prem SharePoint Server. SharePoint Online (cloud) was not vulnerable in the same scope. However, if you run hybrid or are migrating, make sure no on-prem instance remains unpatched.
CTA
- CHORS.NET services — how we work with clients
- NIS2/KSC — obligations and support
- Our AI policy and approach to cybersecurity
- How CHORS.NET works — methodology
Boundaries and assumptions
- We are not a 24/7 SOC and do not guarantee detection of every incident.
- We do not certify NIS2/KSC compliance and do not issue standalone legal opinions.
- Findings reflect the state as of the article date (18 Aug 2026); technical details may change with vendor updates.
- For legal interpretation CHORS works with law firms.
- Informational and technical material; not legal advice. Implement changes per your organization's policy and test in a non-production environment first.