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.
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:
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.
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).
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
Now for the probably most important part, here is everything you should do to if your system is in the list of affected versions:
All of this can be found in Microsoft’s Customer guidance for SharePoint vulnerability CVE-2025-53770 .
After implementing those fixes, you probably want to investigate if you were compromised!
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:
User agent strings used:
Headers / Pages:
Paths on the SharePoint Servers:
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: