July 2025 Microsoft SharePoint Server exploit: What SharePoint Admins need to know
Table of contents
Over a billion people use SharePoint every day, but every SharePoint admin knows that if you open the news and you hear everyone talking about SharePoint, it’s never a good sign. This Monday, particularly, was a bad one for SharePoint Server administrators around the world as a new zero-day vulnerability became public, and already multiple U.S federal agencies, state agencies, energy companies, and more have been hit. In this blog post, we will break down what SharePoint admins need to know (and do) right away, as well as share multiple links where you can learn more about this attack.
Impact of the exploit and affected servers
This vulnerability only affects SharePoint Server (on-premises) editions and does not affect SharePoint Online in Microsoft 365 at all. Therefore, if your organizations or clients only runs SharePoint online, you can now relax (but feel free to read on to understand how this happened)! More specifically this targets:
- SharePoint Server Subscription Edition (SE)
- SharePoint Server 2019
- SharePoint Server 2016
While I did not find anything in official documentation, some IT professionals on Reddit confirmed that this also happened on SharePoint Server 2013. Given the DLLs exploited, SharePoint Server 2010 is also at risk, but I couldn’t find official documentation on 2010/2013 at the time of writing this blog post. Remember that SharePoint 2010 and 2013 are not supported anymore, so if you’re running on those versions, there is a chance Microsoft might not release a patch for those versions.
In terms of impact, security company Eye Security found over 8,000 publicly accessible SharePoint farms that were open to the vulnerability, including dozens that were already affected by it. In addition, I didn’t find this mentioned in many articles. Still, even if your SharePoint server is not open to the internet, if your network is already compromised by a user with no permission to access SharePoint, this zero-day exploit puts your SharePoint servers at risk.
What happened?
On July 18, 2025, security researchers observed active, large-scale attacks against on-premises SharePoint servers exploiting a previously unknown vulnerability. The Dutch firm Eye Security was the first to raise the alarm after detecting a suspicious file upload on a client’s SharePoint server – an ASPX web shell that attackers had used to gain remote code execution (RCE) without any valid login. It quickly became clear this was no ordinary breach: the attackers were exploiting a “zero-day” flaw (meaning no prior patch existed) to drop web shells, steal sensitive data, and seize control of SharePoint servers across multiple organizations.
Microsoft confirmed the issue soon after, assigning it CVE-2025-53770 (now nicknamed “ToolShell”) and acknowledging active attacks in the wild. A second related bug, CVE-2025-53771, was also identified. Together, these could be chained for unauthenticated RCE on vulnerable SharePoint instances.
At first, no patch was available, and Microsoft told admins to assume their SharePoint farms were breached and start hunting for signs of compromise. We now have patches and instructions available. More on that in a bit. If you run SharePoint Server 2010 or higher, follow the Zero Trust principles of Assume Breach and clear your next few days of meetings to start investigating if your SharePoint Server has been breached. In just a few minutes, I will share a compilation of things to look for (and measures to take).
Understanding the vulnerabilities (ToolShell Exploit Chain)
Later in this blog post, I will give you links for the super detailed and technical explanation of this exploit, but in this blog, let me make it simple for SharePoint administrators. This exploit allows a hacker to trick the SharePoint server into accepting a malicious request without logging in, and then allows the attacker to execute code on the server. So as soon as someone can get to any point of your SharePoint farm (ex, getting to a WebApp URL, or any login page), they can make SharePoint server skip any authentication/authorization and get admin rights on all your SharePoint Servers.
Confirmation of exploit at Pwn2Own Berlin 2025
This vulnerability was first discovered at a hacking contest (Pwn2Own Berlin 2025) by security researchers, who reported the bugs CVE-2025-49706 (auth bypass) and CVE-2025-49704 (RCE) to Microsoft. Microsoft had issued a Patch Tuesday update in early July that partially addressed these issues. Still, unfortunately, the fix wasn’t complete as attackers discovered a gap – by adding a crafty HTTP Referrer header (/_layouts/SignOut.aspx) in their request, they could bypass the remaining authentication check. This turned the previously patched bug into a zero-day again, now tracked as CVE-2025-53770.
It’s a mix of two vulnerabilities that make this exploit possible, and the industry calls it ToolShell. The scary part of it is that the attacker sends a single specially crafted POST to a SharePoint page (ToolPane.aspx) with the malicious payload. Because of the auth bypass, the server processes it like an authenticated request. This payload triggers SharePoint to deserialize untrusted data (a known dangerous operation), allowing the attacker to run code on the server before any user authentication happens. Essentially, the attacker can drop malware on the server at will.
Once inside your SharePoint server, current attacks show that attackers have been stealing the SharePoint server’s Machine Key configuration – specifically the cryptographic keys (ASP.NET ValidationKey and DecryptionKey) that SharePoint uses to secure authentication tokens and viewstate data.
With these keys, the attacker can forge their own “trusted” data and requests to the server. This means they can persist access even after you patch the server. Once you patch everything, you will need to update those keys! If you do not, attackers will be able to keep full control while hiding behind normal SharePoint operations and basically giving them stealthy, persistent access, even after patching
What you should do right away
Now for the probably most important part, here is everything you should do to if your system is in the list of affected versions:
- Apply the latest security updates, including the July 2025 Security Update
- Security Update for Microsoft SharePoint Server Subscription Edition (KB5002768)
- Security Update for Microsoft SharePoint Server 2019 Core (KB5002754)
- There is no SharePoint 2016 update yet but make sure you check this page often.
- Ensure the Antimalware Scan Interface (AMSI) is turned on and configured correctly, with an appropriate antivirus solution such as Defender Antivirus.
- Deploy Microsoft Defender for Endpoint protection, or equivalent threat solutions.
- Rotate SharePoint Server ASP.NET machine keys
- This can either be done via the Central Administration
- Central Admin > Monitoring > Review Job Definition > Machine Key Rotation Job > Run Now
- This can also be done via PowerShell using the Update-SPMachineKey cmdlet.
- This can either be done via the Central Administration
- After rotating the keys, restart IIS on all servers in the farm
All of this can be found in Microsoft’s Customer guidance for SharePoint vulnerability CVE-2025-53770 .
- Other recommendations from the community include blocking a POST to /_layouts/15/ToolPage.aspx in order to prevent the payload from being installed.
After implementing those fixes, you probably want to investigate if you were compromised!
ToolShell Indicators of Compromise (IOC’s)
After you implement the fixes, you should check your Security Information and Event Management (SIEM), or your Security Orchestration, Automation, and Response (SOAR), or of course as simple as other security logs if any of the following signs are found:
IP Addresses linked to the attack:
- 107.191.58[.]76
- 104.238.159[.]149
- 96.9.125[.]147
- 45.77.155[.]170
User agent strings used:
- Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:120.0) Gecko/20100101 Firefox/120.0
- Mozilla/5.0+(Windows+NT+10.0;+Win64;+x64;+rv:120.0)+Gecko/20100101+Firefox/120.0
Headers / Pages:
- /_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx (POST path used to trigger exploit)
- /_layouts/SignOut.aspx (exact HTTP header used in exploiting ToolPane.aspx)
- /_layouts/15/spinstall0.aspx (GET request to malicious ASPX file)
Paths on the SharePoint Servers:
- C:\PROGRA~1\COMMON~1\MICROS~1\WEBSER~1\16\TEMPLATE\LAYOUTS\spinstall0.aspx
More in-depth information
While I tried to cover the basics in this post, there is a lot of interesting and more in-depth information about this exploit at the following links:
