ToolShell and on-prem SharePoint exposure: are your controls ready?

TL;DR: Microsoft’s out-of-band fixes for ToolShell-related SharePoint flaws came after attackers chained CVE-2025-53770 and CVE-2025-53771, with Orca Security finding 13% of cloud environments still run vulnerable self-hosted SharePoint components and 6% expose them directly to the internet. The real issue is not the patch cycle itself, but the persistence of internet-facing, tightly integrated collaboration systems whose trust boundaries are easy to overestimate.

NHIMG editorial — based on content published by Orca Security: Microsoft pushes out-of-band fixes for ToolShell-related SharePoint vulnerabilities

By the numbers:

• Orca Security found that 13% of cloud environments run vulnerable self hosted SharePoint components.
• Orca Security found that 6% expose them directly to the internet.

Questions worth separating out

Q: What breaks when SharePoint servers stay exposed after ToolShell-style flaws are disclosed?

A: What breaks is the assumption that patching alone contains the risk.

Q: Why do on-premise collaboration platforms increase identity-related blast radius?

A: They sit close to the systems that manage access, documents, and administration, so a server compromise can become a path into identity-adjacent trust relationships.

Q: How do security teams know whether ToolShell remediation is actually complete?

A: They should verify that every affected SharePoint instance is patched, publicly exposed systems are removed from reach until fixed, and machineKey values have been rotated with IIS recycled.

Practitioner guidance

• Harden internet exposure for on-prem SharePoint Inventory every self-hosted SharePoint instance, confirm whether it is directly reachable from the internet, and remove public access until the July 2025 fixes and required KBs are verified on each host.
• Rotate machineKey material across the estate Regenerate ValidationKey and DecryptionKey values on every SharePoint server, then recycle IIS so the new keys are enforced consistently across the environment.
• Hunt for post-exploit web shells and request forgery Sweep SharePoint directories for unexpected ASPX files, inspect HTTP logs for suspicious ToolPane.aspx requests, and treat the Referer spoofing pattern as an indicator of active exploitation.

What's in the full article

Orca Security's full article covers the operational detail this post intentionally leaves for the source:

• Exact vulnerable SharePoint build references and the KB numbers that map to each affected release.
• Concrete response steps for generating fresh ASP.NET machineKey values and validating IIS recycle behaviour.
• Indicator-of-compromise details including dropped file names, suspicious request paths, and external IP addresses.
• Orca Platform workflow examples showing how exposed SharePoint instances are identified and prioritised.

👉 Read Orca Security's analysis of the ToolShell SharePoint exploit chain →

ToolShell and on-prem SharePoint exposure: are your controls ready?

Explore further

View Full Forum →  |  NHI Foundation Course →