SharePoint's Zero-Day Nightmare: Unpacking CVE-2025-53770 and Why Patching Isn't Enough

You did the right thing. You saw the alerts, you scrambled the team and you patched SharePoint. You followed the playbook. The server is updated. The vulnerability is gone.

But there’s a cold feeling in your gut. A thought that keeps you up at night, pulled straight from the mouths of your fellow sysadmins: What is even in our SharePoint?

It’s a digital attic. A data graveyard with no map. Years of contracts, PII, stale credentials and forgotten projects. And a nasty new zero-day, CVE-2025-53770, just kicked the door in. If someone got in, you’d have a hard time saying what they saw or what they took.

Let’s be clear: this isn’t just a vulnerability. It’s a full-blown identity crisis for anyone running SharePoint on-premises.

The Target: SharePoint’s Unseen Kingdom

First, you have to respect the target. On-premises SharePoint isn’t just a document library; for many organizations, it’s the central nervous system. It’s deeply integrated with Office, Teams and Outlook. It holds the crown jewels:

• Sensitive Data: HR records, financial reports, legal contracts.
• Intellectual Property: Source code, strategic plans, research.
• Infrastructure Secrets: Internal configurations, passwords and service account details buried in web.config files.

A breach here isn’t a simple data leak. It’s a catastrophic failure. As Palo Alto Networks’ Unit 42 put it, a compromise “doesn’t stay contained, it opens the door to the entire network.” They—and CISA—are urging anyone with an internet-facing on-prem SharePoint server to assume they have been compromised.

The Prequel: The “ToolShell” Chain

To understand this new nightmare, you have to know the one that came before it. In May, researchers chained two bugs (CVE-2025-49704 and CVE-2025-49706) at Pwn2Own to get remote code execution (RCE). They called it “ToolShell.”

Microsoft patched it in July. Case closed, right?

Wrong. The attackers just found a better way in. CVE-2025-53770 is a variant, a clever bypass of the original fix. It’s more potent, unauthenticated and scores a blistering 9.8 CRITICAL on the CVSS scale.

The Bypass: How an Unauthenticated Attacker Owns Your Server

This isn’t a brute-force attack. It’s an elegant abuse of trust. The vulnerability is a classic case of Deserialization of Untrusted Data (CWE-502).

The attacker targets a specific, obscure endpoint: /_layouts/15/ToolPane.aspx. They send a request to edit a web part that shouldn’t be editable. Inside this request, they inject a malicious XML payload.

This is what the skeleton key looks like, according to the public proof-of-concept:

<asp:UpdateProgress ID="UpdateProgress1" runat="server" AssociatedUpdatePanelID="upTest">
  <ProgressTemplate>
    <div class="divWaiting">
      <Scorecard:ExcelDataSet CompressedDataTable="{PAYLOAD}" DataTable-CaseSensitive="false" runat="server" />
    </div>
  </ProgressTemplate>
</asp:UpdateProgress>

The magic is in the <Scorecard:ExcelDataSet> component and its CompressedDataTable attribute. The attacker crafts a malicious .NET object (a “gadget chain”), serializes it, compresses it with GZIP and Base64-encodes it. This toxic blob becomes the {PAYLOAD}.

When SharePoint receives this, it dutifully decodes, decompresses and deserializes the object to process it. It doesn’t check what it’s deserializing. And in that moment, the attacker’s code runs with the permissions of the IIS worker process (w3wp.exe). Game over.

The Heist: What Attackers Are Doing Right Now

Security researchers at Unit 42 have seen this exploit in the wild and it’s ugly. Attackers aren’t just popping shells; they’re systematically dismantling your security.

Variation 1: Stealing Secrets

First, they go for the keys to the kingdom. They execute a PowerShell command to hunt for all web.config files and dump their contents into a public-facing JavaScript file. These files often contain database connection strings, API keys and the validationKey and decryptionKey for the server.

powershell -c "ls -r C:\inetpub\wwwroot\wss\VirtualDirectories -i web.config | select -exp fullname | % { gc $_ | Out-File -Append C:\'Program Files'\'Common Files'\'microsoft shared'\'Web Server Extensions'\16\TEMPLATE\LAYOUTS\debug_dev.js}"

Variation 2 & 3: Planting a Permanent Backdoor

Next, they establish persistence. The IIS process (w3wp.exe) is seen spawning a command shell to run a Base64-encoded PowerShell script.

cmd.exe /c powershell -enc JABiAGEAcwBlADYANABzAHQAcgBpAG4AZwAgAD0AIAAiAEgAVABUAUAAvADEALgAxACAA[...]AgAGwAZQBlAHAAKAAxADAAMAApADsA

This alphabet soup decodes into a script that writes a web shell, spinstall0.aspx, deep inside the SharePoint layouts directory. This shell allows them to execute commands, steal more credentials and forge authentication keys to impersonate any user—bypassing MFA and SSO entirely. The attackers are so thorough they even have variations that write to different SharePoint version directories (.../15/TEMPLATE/... for 2013/2016 and .../16/TEMPLATE/... for 2019/Subscription).

The Damage Control: Your New Battle Plan

Feeling paranoid? Good. Now, let’s channel that into action. This is not a standard patch-and-move-on scenario. This is incident response.

Step 0: Assume Breach

If you have an on-prem SharePoint server, especially one exposed to the internet, act as if you are already compromised. Patching alone will not evict an attacker who has already established a foothold.

Step 1: Patch Immediately

Microsoft has released security updates. These are cumulative and absolutely critical. Apply them now.

Step 2: Enable AMSI (Antimalware Scan Interface)

This is your most powerful mitigation. AMSI allows your antivirus solution (like Microsoft Defender) to inspect the content of requests before they are processed by SharePoint. According to Microsoft, this protects you from this specific unauthenticated attack vector.

If you can’t enable AMSI, CISA’s advice is blunt: disconnect the server from the internet.

Step 3: Rotate Your Keys. Then Rotate Them Again.

An attacker with your machine keys can forge authentication cookies forever. You must invalidate them. Microsoft’s updated guidance is a multi-step process:

1. Rotate your ASP.NET machine keys before patching.
2. Apply the security updates from Step 1.
3. Rotate your ASP.NET machine keys again.
4. Restart IIS on all SharePoint servers (iisreset.exe).

Use PowerShell to manage the key rotation:

# Generate the machine key
Set-SPMachineKey -WebApplication <SPWebApplicationPipeBind>

# Deploy the key to the farm
Update-SPMachineKey -WebApplication <SPWebApplicationPipeBind>

Step 4: Hunt for Intruders

You need to actively look for footprints. Microsoft and Unit 42 have provided hunting queries for their security tools.

Microsoft 365 Defender - Look for the webshell:

DeviceFileEvents
| where FolderPath has_any (@'microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS', @'microsoft shared\Web Server Extensions\15\TEMPLATE\LAYOUTS')
| where FileName has "spinstall0"
| project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, FolderPath, ReportId, ActionType, SHA256
| order by Timestamp desc

Cortex XDR - Look for suspicious file writes:

// Description: This query identifies specific files being written to the observed file paths during exploitation.
dataset = xdr_data
| fields _time, agent_hostname, causality_actor_process_image_name, causality_actor_process_command_line, actor_process_image_name, actor_process_command_line, action_file_name, action_file_path, action_file_extension, action_file_sha256, event_type, event_sub_type
| filter event_type = ENUM.FILE and event_sub_type in (ENUM.FILE_WRITE, ENUM.FILE_CREATE_NEW) and lowercase(action_file_path) ~= "web server extensions\\1[5-6]\\template\\layouts" and lowercase(action_file_extension) in ("asp", "aspx", "js", "txt", "css")
| filter lowercase(actor_process_image_name) in ("powershell.exe", "cmd.exe", "w3wp.exe")
| comp values(action_file_name) as action_file_name, values(action_file_path) as action_file_path, values(actor_process_command_line) as actor_process_command_line by agent_hostname, actor_process_image_name addrawdata = true

Conclusion: The Game Never Ends

This vulnerability is a brutal reminder of a lesson we keep having to learn: the most dangerous attacks don’t just break the rules; they weaponize them. They use the system’s own features against it with devastating precision.

The panic over CVE-2025-53770 isn’t just about a technical flaw. It’s about the sudden, terrifying realization that we are often custodians of data we don’t fully understand or govern. You can patch the server, but you can’t patch a decade of digital sprawl overnight.

The real monster isn’t the zero-day. It was the data graveyard we let it roam in. Don’t let them find the ghosts in your machine.

Frequently Asked Questions (FAQ)

What is CVE-2025-53770?

It is a critical remote code execution (RCE) vulnerability in on-premises Microsoft SharePoint Server. It allows an unauthenticated attacker to execute code over the network by exploiting an insecure deserialization flaw. It has a CVSS score of 9.8 and is being actively exploited in the wild.

Is my SharePoint Online (Microsoft 365) instance affected?

No. Microsoft has confirmed that SharePoint Online is not impacted by this vulnerability. This issue applies only to on-premises installations of SharePoint Server 2016, SharePoint Server 2019 and SharePoint Server Subscription Edition.

What is the first thing I should do to protect my servers?

Your immediate priorities are:

1. Apply the latest security updates from Microsoft.
2. Ensure AMSI integration is enabled with a compatible antivirus solution like Microsoft Defender.
3. If you cannot do the above, disconnect your SharePoint server from the internet until it can be secured.

How do I know if I’ve been compromised?

Assume you have been and investigate. Use the hunting queries provided in this article to search your logs for signs of exploitation, such as the creation of the spinstall0.aspx webshell or commands reading web.config files. Check for unusual w3wp.exe process behavior. A full compromise assessment from a professional incident response team is highly recommended.