A Word on Microsoft and Vulnerability Exploitation

Intro

Microsoft Security Response Center (MSRC) is the group responsible for triage when researchers report new vulnerabilities. They handle a wide variety of other tasks, but my focus is on their analysis of vulnerabilities in one context or another. That could be the researcher’s disclosure or investigating an actively exploited vulnerability in a customer environment. At some point in the past, MSRC’s security advisories started adding metadata around exploitation. You can see it in this advisory for CVE-2025-21174. The relevant parts:

Publicly disclosed	No
Exploited	No
Exploitability assessment	Exploitation Less Likely

These attributes and potential values are explained in their Microsoft Exploitability Index. In addition to the yes/no possibility for ‘Exploited’, they go on to define the four possible values for ‘Exploitability assessment’. Here are slightly abbreviated summaries:

• 0 – Exploitation Detected – Microsoft is aware of an instance of this vulnerability being exploited. 
• 1 – Exploitation More Likely – Microsoft analysis has shown that exploit code could be created in such a way that an attacker could consistently exploit this vulnerability. Moreover, Microsoft is aware of past instances of this type of vulnerability being exploited.
• 2 – Exploitation Less Likely – Microsoft analysis has shown that while exploit code could be created, an attacker would likely have difficulty creating the code, requiring expertise and/or sophisticated timing, and/or varied results when targeting the affected product. Moreover, Microsoft has not recently observed a trend of this type of vulnerability being actively exploited in the wild.
• 3 – Exploitation Unlikely – Microsoft analysis shows that successfully functioning exploit code is unlikely to be utilized in real attacks. This means that while it might be possible for exploit code to be released that could trigger the vulnerability and cause abnormal behavior, the full impact of exploitation will be more limited. Moreover, Microsoft has not observed instances of this type of vulnerability being actively exploited in the past.

These values are also represented in the CVSSv3.1 string provided. For example, CVE-2025-21174 gives us “CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H/E:U/RL:O/RC:C”. The CVSS exploit metric, defined by “E:” has four possible values, abbreviated here:

• Not Defined (X) – Assigning this value indicates there is insufficient information to choose one of the other values, and has no impact on the overall Temporal Score, i.e., it has the same effect on scoring as assigning High.
• High (H) – Functional autonomous code exists, or no exploit is required (manual trigger) and details are widely available. Exploit code works in every situation, or is actively being delivered via an autonomous agent (such as a worm or virus).
• Functional (F) – Functional exploit code is available. The code works in most situations where the vulnerability exists.
• Proof-of-Concept (P) – Proof-of-concept exploit code is available, or an attack demonstration is not practical for most systems. The code or technique is not functional in all situations and may require substantial modification by a skilled attacker.
• Unproven (U) – No exploit code is available, or an exploit is theoretical.

Examining the Data

I started by creating a data set that consists of every MSRC security advisory published in 2025, but pulled fresh copies. That means that any updates made to those advisories since publication are included, in case Microsoft has adjusted CVSS scores or exploitability ratings. This includes a CVSS string, if present, as well as MSRC’s exploitability index values. That data was then used to compare to what is available in VulnDB which now has a KEV count of 7,654. That allows for an easy comparison between data sets to pick out discrepancies.

Of the 1,258 CVE IDs in Microsoft advisories from 2025, only 45 are currently Known Exploited Vulnerabilities (KEV). Based on their advisories, a mere 24 were discovered in the wild as zero-day exploits.

A quick note on MSRC CVSS scoring. It is clear that they do not check the scores carefully, nor use any form of automation or business logic checks when publishing. For example, CVE-2025-21333 has the following CVSSv3.1 string, with my bolding as emphasis. Then look at their exploitability index as comparison, with one value bolded to show the contradiction.

CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C

Publicly Disclosed:No;Exploited:Yes;Latest Software Release:Exploitation Detected

The CVSS score (E:U) tells us that MSRC considers it “unknown” if an exploit exists, but if they know it has been exploited then of course a functional exploit exists, even if private. There were seven instances of this happening in their 2025 advisories. If we can’t trust that metric in the score, what else can’t we trust? Turning to Microsoft’s “Exploitability Index“, they have a four-tier scoring index for what they describe as the probability of exploitation:

0	Exploitation detected
1	Exploitation more likely
2	Exploitation less likely
3	Exploitation unlikely

This quickly becomes a problematic metric as well. For CVE-2025-53771 (VulnDB 412292) MSRC has rated exploitation as “Less Likely”. In reality that vulnerability was exploited in the wild before public disclosure making it a zero-day. Since then it has been heavily exploited by Chinese threat actors and ransomware operators including, but not limited to:

APT31 (BRONZE VINEWOOD, JUDGMENT PANDA, Red keres, Violet Typhoon, ZIRCONIUMMinistry of State Security (China)), Linen Typhoon (China), Storm-2603 (GOLD SALEM, Warlock Group (China)), APT6, DEV-0322, G0027, TG-3390, Emissary Panda, BRONZE UNION, Iron Tiger, LuckyMouse, Budworm, Iron Taurus, Brown Worm, GreedyTaotie, TEMP.Hippo, Red Phoenix, Group 35, ZipToken, Earth Smilodon, Circle Typhoon, Linen Typhoon (China)), CL-CRI-1040, LockBit Ransomware, Project AK47, Warlock Ransomware, UNC6357, Earth Alux (REF7707, CL-STA-0049, Ink Dragon (China))

That means that MSRC’s estimate of exploitation was considerably off and despite exploitation two days before their advisory, it still listed the vulnerability as “not” exploited. There are 11 more vulnerabilities that are currently known to be KEV that MSRC listed as “Exploitation Less Likely”. Even worse, there is one vulnerability that is KEV and MSRC listed as “Exploitation Unlikely”, their lowest rating. Beyond that, three of their advisories contained an incomplete scoring string and one had no CVSS scoring string at all. Looking at the entire data set of 1,257 CVE IDs:

Exploitation Detected	28
Exploitation More Likely	128
Exploitation Less Likely	827
Exploitation Unlikely	217
Not scored	58

The takeaway here is that you must scrutinize vulnerability disclosures carefully to look for these discrepancies. When they come from the vendor, often the single source of truth (SSoT), you expect them to have the most accurate information. Unfortunately, as the data above shows, they are not always that.

Note: Here is the aggregated data I used with some coloring for easier consumption.