In mid-July 2025, several of my clients called me about the same thing. Another critical SharePoint on-premises vulnerability had surfaced, this time the ToolShell exploit (CVE-2025-53770 and CVE-2025-53771). I've been through this kind of call before, but the speed and severity were different this time. Attackers were already exploiting it in the wild, mostly against internet-facing servers. Microsoft responded quickly with security updates for SharePoint Server Subscription Edition and 2019, and 2016 followed shortly after. SharePoint Online wasn't affected. For hybrid and on-prem customers, though, it showed once again that the real risk lives on the local servers. Microsoft's guidance was clear, yet many IT teams still had to rush to work out their exposure, get patches installed and, just as important, review their hybrid connections.

ToolShell lets attackers run code on unpatched SharePoint servers

ToolShell is a remote code execution vulnerability in unpatched SharePoint Server installations. CVE-2025-53770 in particular has been exploited actively around the world, with attackers going after externally reachable servers on common web ports. Hybrid environments are still very common in the enterprises I work with, and many of them remain vulnerable. That's especially true where SharePoint front-ends are exposed for legacy integrations or for workflows nobody ever documented properly. If you haven't read them yet, Microsoft's customer guidance and the official CVE entry cover the essentials. Apply the latest security updates, enable AMSI integration in Full Mode with Defender Antivirus, rotate your ASP.NET machine keys and isolate servers at risk. For the AMSI setup itself, the Microsoft Learn article walks you through each step.

# PowerShell on the SharePoint server (admin, latest CU installed)
Set-SPAMSIIntegrationConfig -Enabled $true -Mode Full
Restart-Service w3svc # restart IIS

Requirements: SharePoint Server 2019/Subscription Edition, current CU, Defender Antivirus active.

Every on-prem SharePoint farm needs action right now

If you still run SharePoint Server on-premises or in a hybrid setup, don't rely on auto-updates, and don't assume your monitoring will catch everything. In a lot of the environments I see, hybrid farms still have public endpoints left over, sometimes for a single integration or an old extranet. This isn't something to put off:

  • Apply security updates to every SharePoint server as soon as you can
  • Enable AMSI integration in Full Mode with Defender Antivirus
  • Rotate the ASP.NET machine keys immediately (Set-SPMachineKey / Update-SPMachineKey)
  • Isolate internet-facing servers wherever you can
  • Look for indicators of compromise such as suspicious files, processes or unusual behavior

The machine key rotation matters a lot, and it's the step people skip most often. If you leave the old keys in place, attackers can still hijack sessions or tokens. Microsoft describes the procedure in its guidance post.

Hybrid and on-prem servers remain the weak link

This exploit confirms something I keep running into. On-premises and hybrid SharePoint servers are a weak point that doesn't go away. Even organizations that have "migrated to the cloud" usually keep a few legacy servers for custom integrations, third-party apps or archive access, and those servers are often far more exposed to the outside than anyone thinks. Patching runs behind, advanced monitoring (Defender for Identity, for example) is rarely in place, and hybrid trust paths give attackers a bridge from on-prem to the cloud. If you're still maintaining servers like these, audit your architecture and take a serious look at migration. I've seen it many times: calling yourself "cloud first" doesn't help much when old on-prem workloads keep running in the background.

Practical tip: If you’re not sure where all your SharePoint servers are, spend a day taking inventory and restricting their internet exposure. Even simple geo-blocking at the firewall can buy you some time.

Standard logs won't reveal a ToolShell compromise

The usual event logs won't tell you whether ToolShell got in. Check for suspicious processes, unsigned DLLs in SharePoint's bin folders and PowerShell activity that looks out of place. If Defender is deployed, run a targeted scan and go through the detections in the Microsoft Defender portal. EDR or third-party monitoring tools help flag the lateral movement and persistence techniques attackers rely on.

This is roughly the attack path I'm seeing in practice:

flowchart TD
Internet["Internet"] --> Attack["Attack via port 443/80"]
Attack --> SharePointServer["SharePoint server (unpatched)"]
SharePointServer --> CodeExec["Code execution"]
CodeExec --> Persist["Persistence/lateral movement"]
Persist --> HybridBridge["Hybrid connection to cloud"]
HybridBridge --> CloudTenant["Cloud tenant (potentially)"]

Figure: ToolShell attack path from an unpatched SharePoint server into hybrid environments.

The problem is easy to see. Once an on-premises SharePoint server is compromised, an attacker can move toward cloud resources fairly quickly, especially when privileged accounts or connectors are involved. That links directly to topics like Privileged Identity Management and Conditional Access for hybrid admins.

On-prem SharePoint is still the Achilles’ heel in my view

ToolShell reminds me that on-premises and hybrid SharePoint servers stay near the top of the risk list, even when you patch carefully and follow hardening best practices. The complexity grows every year, and the incident response workload grows with it. If you still have local workloads, you need strict patch discipline, regular key rotation and tight network controls. In the end, only a move to the cloud will put this to rest for good. If you have niche requirements, look at modern app services or reworked workflows, because every legacy server you retire shrinks your attack surface. And one last thing: patching this month's vulnerability doesn't mean you'll get a quiet summer.