A critical zero-day vulnerability in Microsoft SharePoint, tracked as CVE-2025-53770, has been actively exploited since at least July 18th, with no patch available and at least 85 servers already compromised worldwide.
In May, Viettel Cyber Security researchers chained two Microsoft SharePoint flaws, CVE-2025-49706 and CVE-2025-49704, in a "ToolShell" attack demonstrated at Pwn2Own Berlin to achieve remote code execution.
While Microsoft patched both ToolShell flaws as part of the July Patch Tuesday, it is now warning that a variant of CVE-2025-49706, tracked as CVE-2025-53770, is being actively exploited in the wild.
"Microsoft is aware of active attacks targeting on-premises SharePoint Server customers," warns Microsoft.
"The attacks are exploiting a variant of CVE-2025-49706. This vulnerability has been assigned CVE-2025-53770."
Microsoft states that the flaw does not impact Microsoft 365 and is working on a security update, which will be released as soon as possible.
To mitigate the flaw, Microsoft recommends that customers enable AMSI integration in SharePoint and deploy Defender AV on all SharePoint servers.
Microsoft AMSI (Antimalware Scan Interface) is a security feature that allows applications and services to pass potentially malicious content to an installed antivirus solution for real-time scanning. It's commonly used to inspect scripts and code in memory, helping detect and block obfuscated or dynamic threats.
Microsoft says that enabling these mitigations will prevent unauthenticated attacks from exploiting the flaw.
The company notes that this feature is enabled by default since the September 2023 security updates for SharePoint Server 2016/2019 and the Version 23H2 feature update for SharePoint Server Subscription Edition.
If you cannot enable AMSI, Microsoft says that SharePoint servers should be disconnected from the internet until a security update is released.
To detect if a SharePoint server has been compromised, admins can check if the C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\16\TEMPLATE\LAYOUTS\spinstall0.aspx exists.
Microsoft also shared the following Microsoft 365 Defender query that can be used to check for this file:
eviceFileEvents | where FolderPath has "MICROS~1\\WEBSER~1\\16\\TEMPLATE\\LAYOUTS" | where FileName =~ "spinstall0.aspx" or FileName has "spinstall0" | project Timestamp, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine, FileName, FolderPath, ReportId, ActionType, SHA256 | order by Timestamp desc
Further IOCs and technical information are shared below.
Exploited in RCE attacks
The Microsoft SharePoint zero-day attacks were first identified by Dutch cybersecurity firm Eye Security, which told BleepingComputer that over 29 organizations have already been compromised by the attacks.
Eye Security first observed attacks on July 18th after receiving an alert from one of their customers' EDR agents that a suspicious process tied to an uploaded malicious .aspx file was launched.
IIS logs showed that a POST request was made to _layouts/15/ToolPane.aspx with an HTTP referer of /_layouts/SignOut.aspx.
Upon investigation, it was determined that threat actors have weaponized the Pwn2Own ToolShell vulnerability soon after CODE WHITE GmbH replicated the exploit and Soroush Dalili shared further technical details about the web referer last week.
"We have reproduced 'ToolShell', the unauthenticated exploit chain for CVE-2025-49706 + CVE-2025-49704 used by @_l0gg to pop SharePoint at #Pwn2Own Berlin 2025, it's really just one request!," posted CODE WHITE GmbH to X.
Demonstration of the created Microsoft SharePoint ToolShell exploit
Source: CODE WHITE GmbH
As part of the exploitation, attackers upload a file named "spinstall0.aspx," which is used to steal the Microsoft SharePoint server's MachineKey configuration, including the ValidationKey and DecryptionKey.
"Now, with the ToolShell chain (CVE-2025-49706 + CVE-2025-49704), attackers appear to extract the ValidationKey directly from memory or configuration," explains Eye Security.
"Once this cryptographic material is leaked, the attacker can craft fully valid, signed __VIEWSTATE payloads using a tool called ysoserial as shown in the example below.
"Using ysoserial the attacker can generate it's own valid SharePoint tokens for RCE."
Malicious spinstall0.aspx used to steal ValidationKey
Source: BleepingComputer
ViewState is used by ASP.NET, which powers SharePoint, to maintain the state of web controls between web requests. However, if it's not adequately protected or if the server's ValidationKey is exposed, the ViewState can be tampered with to inject malicious code that executes on the server when deserialized.
Eye Security CTO Piet Kerkhofs told BleepingComputer that they have conducted scans of the internet for compromised servers and found 29 organizations impacted in the attacks.
"Although we identified 85+ compromised SharePoint Servers worldwide, we were able to cluster them down to the organizations affected," Kerkhofs told BleepingComputer.
"When clustered, we can confirm 29 organisations have been fallen victim. Of those 29 organisations, there are several multi-nationals and national government entities."
Kerkhofs also told BleepingComputer that some firewall vendors are successfully blocking CVE-2025-49704 payloads attached to HTTP POST requests. However, Kerkhofs warned that if the attackers can bypass the signature, many more SharePoint servers will likely be hit.
The following IOCs were shared to help defenders determine if their SharePoint servers were compromised:
Exploitation from IP address 107.191.58[.]76 seen by Eye Security on July 18th
seen by Eye Security on July 18th Exploitation from IP address 104.238.159[.]149 seen by Eye Security on July 19th.
seen by Eye Security on July 19th. Exploitation from IP address 96.9.125[.]147 seen by Palo Alto Networks.
seen by Palo Alto Networks. Creation of C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\16\TEMPLATE\LAYOUTS\spinstall0.aspx file.
file. IIS logs showing a POST request to _layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx and a HTTP referer of _layouts/SignOut.aspx .
If the presence of any of these IOCs is detected in IIS logs or the file system, administrators should assume their server has been compromised and immediately take it offline.
Further investigations should be conducted to determine if the threat actors spread further to other devices.
This is a developing story and will be updated as new information becomes available.