Critical SharePoint vulnerability CVE-2025-53770: An MSP action guide for ToolShell

If you’re managing SharePoint servers for your clients, you need to act now. CVE-2025-53770 is being actively exploited in the wild, and your clients’ SharePoint servers are potentially sitting ducks.

Here’s what you need to know: This vulnerability lets attackers take complete control of SharePoint servers without any credentials. They’re not just getting in—they’re stealing cryptographic keys that let them maintain access even after you patch. And yes, nation-state actors are already using this.

What’s at risk

Every on-premises SharePoint installation is vulnerable:

• SharePoint 2016
• SharePoint 2019
• SharePoint Subscription Edition
• SharePoint 2013 and earlier (these won’t get patches—they’re no longer supported by Microsoft)

SharePoint Online is safe, but that doesn’t help your on-premises clients. And here’s the kicker: finding vulnerable servers is trivially easy. Anyone can hop on Shodan and search for SharePoint-specific URLs like «/_layouts/15/» to find exposed servers. If you haven’t patched yet, assume you’re already being scanned.

Your immediate action plan

Step 1: Find all SharePoint servers (today)

Start with the obvious—internet-facing servers. But don’t stop there. You need a complete inventory:

• Check Active Directory for SharePoint service accounts
• Scan internal networks for SharePoint URLs
• Review your asset management systems
• Ask clients directly—they might have SharePoint instances you don’t know about

Step 2: Apply patches immediately

Microsoft released emergency patches on July 21-22, 2025:

SharePoint Subscription Edition:KB5002768 (build 16.0.18526.20508)
SharePoint 2019: KB5002754 + KB5002753 (build 16.0.10417.20037)
SharePoint 2016: KB5002760 + KB5002759 (build 16.0.5513.1001)

But here’s the critical part—patching isn’t enough.

Step 3: Rotate the keys (non-negotiable)

Even after patching, attackers who have already compromised servers still have valid cryptographic keys. Here’s exactly what needs to happen:

1. Open SharePoint Management Shell as Administrator on your SharePoint server
2. Generate new machine keys using the Set-SPMachineKey cmdlet. You’ll need to create:
   • A new ValidationKey (128 hexadecimal characters)
   • A new DecryptionKey (48 hexadecimal characters)
   • A new EncryptionKey (48 hexadecimal characters)
3. Apply these keys to EVERY web application in your farm. Each web application needs the new keys or you’re still vulnerable.
4. Restart IIS on ALL SharePoint servers in the farm. This forces SharePoint to start using the new keys immediately.
5. Verify consistency across the farm. The machine keys must match on every server, or you’ll have authentication issues between servers.

Critical timing: This process will cause a brief service interruption as IIS restarts. Plan for 5-10 minutes of downtime, but don’t delay—stolen keys give attackers permanent access until you change them.

Important: If you’re not comfortable with PowerShell or haven’t done this before, get help. Messing up machine key rotation can break authentication across your entire farm. But remember: a broken farm you can fix; a compromised farm might be gone forever.

Step 4: Hunt for compromises

Check for these indicators:

• Web shells named spinstall0.aspx (or variants) in LAYOUTS directories
• PowerShell processes spawned by IIS worker processes
• Connections to known bad IPs: 107.191.58.76, 104.238.159.149, 96.9.125.147
• Unusual file modifications in SharePoint directories since July 18, 2025

Managing the SharePoint Sprawl

Let’s be honest—SharePoint patching is a pain. Unlike regular Windows updates, you can’t just push them through and wipe your hands. Each SharePoint farm needs manual attention, configuration wizards, and testing. Here’s how to handle it at scale:

Automate what you can

Use PowerShell DSC for configuration management. Build scripts that:

• Take pre-patch backups (SharePoint patches can break things)
• Apply patches in the correct order
• Run the Configuration Wizard
• Validate services are running
• Test critical functionality

Document everything

Strong documentation is the foundation of professional risk management and reflects the shared risk responsibility between MSPs and clients. Your risk register should include:

• Every SharePoint instance across all clients
• Version numbers and patch status
• Business criticality ratings
• Decision history and approvals

When clients need to delay patches or accept certain risks, proper documentation ensures both parties understand their role in the shared risk-responsibility model. Risk acceptance forms help clarify the implications—whether it’s potential data exposure, ransomware vulnerability, or compliance impacts. This transparency builds trust and enables informed decision-making within the shared responsibility framework.

Good documentation also speeds up your response to future vulnerabilities. When the next zero-day hits, you’ll know exactly which clients to contact first.

Establish emergency procedures

For critical vulnerabilities like this, you need pre-authorized emergency patching windows. Work with clients now to establish:

• Automatic approval for CVSS 9+ vulnerabilities
• 24-hour patching SLA for internet-facing systems
• 48-hour SLA for internal critical systems

The SharePoint 2013 problem

If clients are still running SharePoint 2013 or earlier, you have two options:

1. Disconnect from the internet immediately
2. Accept that compromise is inevitable

There are no patches coming. Ever. These systems are end-of-life, and this vulnerability is a death sentence for internet-connected legacy SharePoint.

Building long-term resilience

This won’t be the last SharePoint zero-day vulnerability. Here’s what you need for next time:

Maintain visibility

• Deploy continuous vulnerability scanning
• Monitor Microsoft Security Response Center feeds
• Set up alerts for SharePoint-specific threats

Standardize procedures

• Document your SharePoint patching process
• Create runbooks for emergency response
• Train your team on SharePoint-specific quirks

Manage client expectations

• Educate clients on SharePoint risks
• Build security requirements into contracts
• Define clear responsibilities in your MSAs

What this means for your GRC program

As an MSP, you operate under a shared risk-responsibility model with your clients. This vulnerability highlights why robust governance matters:

Your risk register isn’t just paperwork. When Check Point reported 4,600+ attacks on 300+ organizations, MSPs with mature risk management could immediately identify exposed clients and prioritize response. Those without? They’re still scrambling.

The shared risk-responsibility model means your frameworks must address:

• Asset inventory accuracy (you can’t protect what you don’t know about)
• Clear delineation of MSP vs. client responsibilities
• Vulnerability management SLAs that both parties agree to
• Incident response procedures with defined roles
• Client communication protocols that maintain transparency
• Risk acceptance documentation that reflects shared accountability

The bottom line

CVE-2025-53770 is a wake-up call. Chinese nation-state actors are actively exploiting this vulnerability, deploying ransomware, and establishing persistent access. The patches are available, but patching alone won’t save you.

Success requires:

1. Complete visibility of all SharePoint instances
2. Immediate patching of supported versions
3. Key rotation to prevent persistent access
4. Enhanced monitoring for compromise indicators
5. Clear procedures for the next zero-day

Don’t wait for the next client call asking why their SharePoint server is encrypted. Take action now. Your clients are counting on you to keep their collaboration platforms from becoming compromise platforms.

Looking for more blogs on patching, or looking for previous Microsoft Patch Tuesday Reviews, then check out the Patch Management section of our blog.

Lewis Pope is the Head Security Nerd at N‑able. You can follow him on Twitter: @cybersec_nerd

LinkedIn: thesecuritypope

Twitch: cybersec_nerd