SharePoint Vulnerability Exposes Flaws In Security Policies

In recent days, a vulnerability in SharePoint has emerged that has garnered widespread media attention because it was being exploited by a malicious group of Chinese origin. The CVE for the vulnerability is: CVE-2025-53770, which can be read in detail directly on the NVD website: https://nvd.nist.gov/vuln/detail/CVE-2025-53770 or on the Microsoft website: https://msrc.microsoft.com/update-guide/vulnerability/CVE-2025-53770

Reviewing the report, we can see that CVSS is a critical 9.8 vulnerability that can lead to remote code execution, and other things that can quickly frighten anyone responsible for protecting an organization. However, in this column, I want to discuss this, and to do so, I'll contextualize this vulnerability with a real-life scenario.

The vulnerability began being detected and exploited in the wild on the weekend of July 19-20. By the time companies around the world were returning to work on the 20th, alarms about its existence were starting to arise.

I woke up around 5 a.m. PST, and I was already receiving reports from an organization headquarters in Europe with offices in different countries. They had already begun forwarding their threat intelligence reports mentioning the vulnerability to their various operational areas, along with recommendations. In all cases, the recommendation was to apply the official patch.

In all the threat intelligence reports submitted by the various offices, there was one thing in common: the words HIGH, CRITICAL, IMMEDIATE ACTION, MANDATORY, among others.

This quickly led to action. From the first few hours, when the various security managers arrived, they asked the operations or infrastructure teams to immediately begin activities to apply the patch; and it was here that different scenarios arose.

First, given the alert and the emails filled with red, the security team wouldn't accept "no" for an answer, nor would they accept a delay in applying the patch, or any other justification; they believed the patch should be applied immediately, or 24 hours at the most, despite the documented SLA of 36 hours.

For their part, security operatives had a different perspective. Before applying for patches or waiting to receive information from operational areas, they asked themselves: Are we really affected? Yes, there were indeed servers, but how many of these servers were there? In which countries were they located? Were they exposed to the internet? If the company was in the process of migrating to OneDrive, were these servers still active or not? And it was precisely here that the contradictions began.

Why? Because while information security departments said remediation was urgent, computer security departments said, "not so urgent."

I want to pause here, because this is odd. Let's look at two basic definitions.

Risk: The possibility that an uncertain event or condition will occur and have a negative or positive impact on the objectives, resources, or results of an organization, system, or project.

Getting more technical, risk is made up of four elements: threat, vulnerability, probability, and impact.

Meanwhile:

Severity: The magnitude or seriousness of the consequences that an event, incident, failure, or vulnerability can generate, affecting an organization's objectives, resources, or processes.

And very importantly, severity also has two elements: scale, and relationship to risk.

In this relationship with risk, it considers probability and impact, while severity focuses solely on impact. This is the key to this column.

In more mundane terms, what does this mean?

We have a vulnerability with a severity of 9.8 out of 10. That is, a very critical severity; however, the assets, that is, the servers affected by this vulnerability, are a small number; we're talking about 80 servers out of the 2,000 servers the company has. These 80 servers are all on the internal network, without any type of exposure through any remote service. These servers have been migrating to the OneDrive service for some time now, so their information is no longer up-to-date today.

So, is the risk high, equal to, or less than the severity? It's a lower risk. How much lower? I can't really say for sure, because that requires a risk analysis. However, we can say for sure that the risk is lower and doesn’t warrant the emergency that's occurring.

But now let's look at another example within the same organization: CVE 2025-47981, which affects a Windows service; for example, it generally affects all workstations, and has a CVSS of 9.8, the same as SharePoint: https://nvd.nist.gov/vuln/detail/CVE-2025-47981

Well, the organization was also affected by this same CVE, with equal severity. The difference is that this CVE wasn't being exploited by a Chinese organization, it hadn't been in the news, and there were no threat intelligence reports warning about it. Therefore, despite being a critical CVE that, according to the documented SLA, was required to be remediated within 36 hours, they were granted risk acceptance, with the exception allowing remediation within 30 days.

Yet, it's a critical CVE, affecting computers. The company has computers on the internal network, employees in offices using their computers, remote employees working from home on those computers, virtual teams using this gold image in cloud instances, and employees — some of them highly relevant — traveling in airports, client and supplier offices, who were vulnerable. And of the approximately 20,000 assets in the inventory, approximately 10,800 devices were found to be affected.

Without performing a detailed risk analysis, is the risk between both CVEs greater or different? Should actions have been taken differently in each case?

The basic answer is, if there is a process based on severity, and that process tells us that a severity of 9.8 must be remediated within 36 hours, regardless of which of the two CVEs is being addressed, the timeframe should be the same for both.

However, this response is the basic response in an incorrect process, as this process does not consider risk as a primary element.

How can we solve this? The reality is that the CVSS calculator itself gives us the solution. Although we have the base vectors from which the value published in the CVEs is derived:

We also have environmental vectors, which allow us to determine the conditions of the affected assets and obtain a value aligned with our organization:

And while it's not as accurate as a risk analysis focused on our organization, it gives us a much more accurate view than simply using the CVSS that comes with the CVEs.

But, in case the bias I've outlined isn't clear. Let's take an example at the other extreme: a low CVSS vulnerability. The classic "clear text protocols" vulnerability, which is when we encounter a vulnerability analysis or pentest where the infrastructure is using HTTP, Telnet, or FTP, which we know are easily intercepted. The CVSS associated with this is 4, which is still within the low limit. This implies that the remediation policy applied to them will always be quite lax. I've usually seen the average being 90 days in organizations. In some cases, despite the SLA, they are not remediated because they are not taken into account during audits.

A CVSS 4.0 rating would be, under the logic of using CVSS as the sole decision-making factor, low. However, if a malicious user intercepts domain credentials — for example, traveling from a Windows computer in Active Directory to a mainframe via Telnet, which is quite common — with those same credentials, they would have compromised the entire domain. And for those who are not technically inclined, this is a matter of opening an application called Wireshark, clicking the "Capture" button, and waiting. It's that simple.

Another very common example is that in dynamic application scans, issues with expired certificates, old TLS versions, and others, often arise. However, intercepting information from an old TLS can be very complicated. It's not the same process as just running Wireshark and waiting.

Do you get the idea?

And don't get me wrong, I'm not against the use of CVSS. What I'm criticizing is its misuse by information security and cybersecurity departments, which don't take into account the risk factors to truly understand them. This leads them to make erroneous decisions.

Have you reviewed your vulnerability management policy?