The zero-day in Microsoft SharePoint (CVE-2025-53770 and CVE-2025-53771) have been known for a few days now. What exactly happened, how was the zero-day discovered, and are we sure we caught it in time (if that’s possible)? Also, if you haven’t taken action yet, even if you think you’re not affected, you should do something about it fast. Patching along isn’t enough.
CVE-2025-53770 and CVE-2025-53771 are very serious vulnerabilities. There are several reasons for this. First of all, there is the fact that this is a Microsoft product, a company with a huge installed base. The on-premises versions of SharePoint affected by this vulnerability (SharePoint Server 2019, SharePoint Server 2016, and SharePoint Server Subscription Edition) are still in use in quite a few places. These are mainly environments where this is likely a conscious and/or enforced choice. In other words, environments that cannot or are not allowed to choose the online version of SharePoint.
The above customers are often targets of high importance for attackers. They often include governments, but also telecom companies, for example. That was certainly the case with this attack as well, according to a report by Check Point Research. Therefore, it seems pretty safe to us to assume that the attack came from the a state actor, or at least hackers with ties to a government that is unfriendly to the Western societies, in particular the U.S.
Relatively easy, but with a big impact
A second reason why this is a very serious zero-day has to do with the combination of execution and impact from the attackers’ perspective. CVE-2025-53770 and CVE-2025-53771 have the ideal combination of these two factors: their impact is high and they are easy to execute. Hackers do not need to worry about obtaining login credentials or cracking MFA and SSO. In other words, they do not need to authenticate themselves. The attack neatly circumvents this. Attackers exploit vulnerabilities in SharePoint to ultimately run code in SharePoint completely ‘legally’.
Once attackers have reached the RCE (Remote Code Execution) stage, they can also start snooping around in other parts of the system. Since SharePoint is often integrated into environments that also run Office, Teams, OneDrive, and Outlook, the potential payoff for attackers is enormous. It gives them a direct line to a large portion of the important data that organizations have.
How did Eye Security discover the SharePoint zero-day?
The Dutch security company Eye Security was the first to publish widely about the CVE-2025-53770 and CVE-2025-53771 zero-day in Microsoft SharePoint. In an excellent post, the company explains how it went about its work.
A few days before Eye Security reported on it, another company, Code White from Germany, had already revealed on X that several known CVEs, namely CVE-2025-49706 and CVD-2025-49704 (later known as CVE-2025-53770 and CVE-2025-53771, even though Microsoft had already released partial patches for the original vulnerabilities), could be used together as the exploit it called “ToolShell.” This had previously been used at Pwn2Own in Berlin to hack SharePoint. That event took place between May 15 and 17, 2025.
Was the zero-day discovered in time?
With the above timeline in mind, you may wonder whether Eye Security caught it in time. After all, there was a month between the demo during Pwn2Own and the moment the company discovered it. Who’s to say it wasn’t exploited well before July 18? According to Eye Security’s report, at the time of the demo, virtually nothing was known about how this attack worked. No public code and virtually no other details. The HTTP Referer header that, according to the company, could have promoted the original CVE-2025-49706 vulnerability to zero-day (CVE-2025-53770) was only discovered publicly on July 17.
Was this person on X really the first to fuzz the HTTP Referer header (i.e., expose it as the culprit)? And thus uncover the authentication bypass in SharePoint? Based on the sharp increase in attacks last weekend, that could well be the case.
However, a report by Check Point Research contains some information that indicates something else. According to the company’s researchers, attempts to exploit the vulnerabilities had already been made on July 7. At that time, they may not have been successful. Or perhaps they were, and we only found out after Eye Security took a closer look after receiving an alert from Crowdstrike Falcon EDR at one of its customers in the evening. In any case, the fact is that the attacks were significantly increased on July 18 and 19.
Link to Ivanti EPPM vulnerability
In addition to reporting that it had already detected attempts to exploit the zero-day in Microsoft SharePoint on July 7, the Check Point Research report contains something else of interest. The company’s researchers found a link to several Ivanti vulnerabilities. There have been quite a few of these in recent years. In this case, it specifically concerns CVE-2025-4427 and CVE-2025-4428. One of the IP addresses that Check Point says was used for the attacks on Microsoft SharePoint is also linked to attacks that exploited the Ivanti vulnerabilities.
Check Point Research then concludes that “attackers exploited known Ivanti vulnerabilities during the campaign.” We have not seen any concrete evidence of this in the report, except for a similarity in the infrastructure used. In itself, this is not particularly unusual. We saw the same thing with the Ivanti vulnerabilities. However, we assume that Check Point is not just saying this and that they have indeed seen evidence of it. It is striking that one of the Ivanti vulnerabilities also involves bypassing authentication, which is also an important component of Microsoft’s SharePoint zero-day.
If attackers actively exploited the Ivanti vulnerabilities during the attacks on on-premises SharePoint environments, this could mean that there are still organizations that have not yet patched the Ivanti vulnerabilities. These have been available since May 13. It is also possible that these patches were not sufficient to ensure complete security.
Patching alone is not enough
The “ToolShell” attack linked to CVE-2025-53770 and CVE-2025-53771 is quite sophisticated. Once inside, attackers can remain undetected. This is possible because the attackers have stolen ASP.NET machine keys. These are keys that validate and encrypt data within an ASP.NET application. They are not one-time keys and can therefore be reused. Once an attacker is inside, they can continue their work even after the vulnerabilities have been patched.
To prevent this, it is necessary to develop new keys and start using them. This is obviously important for servers that have been demonstrably attacked. However, to be on the safe side, we would also do this for all other on-prem SharePoint servers that organizations still have in place.
In addition to renewing the ASP.NET machine keys, it is of course important to install the patches. These are now available for all three affected environments. It is also important not to try to do this all yourself. Call in Incident Response teams or one of the security companies you work with.