Introduction
OK loyal readers, this blog could have been almost two decades in the making. Because the root-cause of this blog goes back that far, truly. The only reason things are slightly different now is due to the volume of disclosures and subsequent advisories from Microsoft this year. To better understand that you need to appreciate how the Microsoft Security Response Center (MSRC) operates. I’ll do my best not to go into too much of the history, which includes the ebb and flow of their actual responses to their primary contact email. I’ve had my fair share of dealings with them, but not in a “I am reporting a vulnerability” capacity, rather in a “I have questions…” context. They do pretty well historically in the former, certainly not the latter. I’ve had to reach out via backchannels to get answers for the most basics of questions seeking clarity about their disclosures way too often.
Let me go on a side tangent here based on the last sentence. For a security response team that triages incoming vulnerability reports, that has more than one component. Of course there is the incoming vulnerability report itself. Eventually it leads to an e.g. Microsoft advisory if it meets criteria, sure, but sorry to say, that also means confusion or outright errors at times. Judging a SIRT / PSIRT absolutely cannot be done solely based on the initial disclosure and coordinated vulnerability disclosure (CVD) that results. To me, the real test of a SIRT / PSIRT comes in the follow-up. If they can’t be bothered to clarify a CVE assignment, affected products, or exploitation prerequisites? They don’t get a passing grade.
Microsoft will be my whipping boy in this blog, but rest assured, they certainly are not the only vendor; not even major vendor. This is a timely choice though because they have been put on a pedestal of vulnerability statistics masturbation lately, and of course, all the usual suspects in our industry don’t seem to understand much about this particular point. I’m looking at you vulnerability tourists, academics, and other clowns I have called out.
Honestly, in a perfect world this blog could be all of a few sentences but it might be overlooked then. More importantly though, I have to be a bit wordy because I don’t think MSRC has all of these points clearly documented which should also be a crime in this day and era. And now the fun part, let’s go down this rabbit hole together, because almost every blog I have to go hunt citations and generate statistics. That is often educational because what I “know” often quickly becomes what I “knew”, past tense, as additional information and knowledge are consumed. This is also where my blogs quickly become scope-creep. I love that Wikipedia is my frequent partner in explaining certain concepts though. I’ll also apologize in advance, this blog suffered the “too many edits and re-writes” and I know it still feels a little disjointed, but I have to move on.
The “Now”
With the recent so-called Vulnpocalyse, the amount of disclosures has gone up substantially. As someone who works on VulnDB, perhaps the most comprehensive vulnerability database (VDB) out there, I can assure you this is a real thing. Disclosure volumes have skyrocketed and all those LinkedIn posts you see are correct, in general. Of course, they are using CVE data which is drastically incomplete and based on an ecosystem that is horribly flawed. Forgetting that, the numbers are certainly up and Microsoft has become an archetype of this phenomenon.
Security pundits absolutely love to use Microsoft as an example because of historic trends. They tend to think that history versus today has a 1:1 relationship when it never actually did. I mean, it kind of did, sort-of maybe depending on your approach? That’s the beauty of this blog! I get to hedge all day long and none of you readers get to argue with me because I am 100% correct about the topic at hand and you can’t prove me wrong. The best kind of blog! =)
Yes, Microsoft (and others) are absolutely up in disclosures over the last six months due to the so-called Vulnpoaclypse. Past that you really can’t talk about much other than “the numbers are up”, and you most certainly cannot talk about actual statistics here if you want to compare true vulnerability counts. You can begin to if you fully and loudly disclaim all the caveats but no one has done that that I have ever seen in my life when it comes to Microsoft. Note the bold there, because that is a strong statement I know, yet true. You can compare prior Microsoft disclosures to current all day long as long as you disclaim everything carefully, but that’s a long list of explanations that will accompany it. You cannot talk about and compare the number of vulnerabilities actually patched from a prior month to a subsequent month, and that statement holds true for the last two decades as well.
You may think that comparing a prior month to this month is fine because Microsoft hasn’t changed their criteria for publication, but that is irrelevant. Why? You have to trust Microsoft’s CVSS scoring which dictates if they publish an advisory, along with other aspects of triage such as declaring an issue “not a vulnerability”. Like every major CVE Numbering Authority (CNA), they have a history of inaccurate CVSS assignments. The numbers of disclosures between months will generally be comparable but that is yet another disclaimer you must include. Additionally, one must be careful on using words like “ever” and replace them with “so far” unless you think the trend will change in which case that is a much bigger observation potentially.
The Nitty Gritty
Checking the MSRC page for CVD now, I see they are still boasting big awards via their bounty program. I’m sure they are but for ages this was stupidly limited to a few products with very specific criteria. This page makes it seem like Microsoft pays out “Big Awards” for vulnerabilities in all of their software regardless. That is not the case. Not now, not historically either. This is deceiving for any budding vulnerability researchers. Must be first… must follow CVD… must work “within the Rules of Engagement”… must be this software… must be this severe… and if you read between the lines, you can actually see a major point of this blog!
Do you see anything about the severity of the vulnerability, anywhere? I don’t. There’s a good reason for that. What Microsoft doesn’t advertise is that they will only issue an advisory if your vulnerability rates a certain severity level that is determined by Microsoft themselves, not necessarily determined based on reality. Did you find a “memory disclosure” vulnerability that is considered low-risk by most standards? Sorry, no guarantee on an advisory for you! Oh, you mean that such vulnerabilities are increasingly vital for exploitation in an exploit chain? Move on kid, still doesn’t necessarily get an advisory.
If we look at the recent “php2shell” nightmare that is currently not only plaguing the world, but causing serious confusion over actual exploitation and capability to exploit, it requires such a low-risk vulnerability to make full exploitation possible. The problem is that a memory layout disclosure vulnerability is considered low risk by itself in many cases and would be scored “low” by the Common Vulnerability Scoring System (CVSS) frameworks, all three of them at times. Versions 2, 3, and 4 would put that as below 5.0 for many cases, meaning it would be considered “low risk” by itself. The vulnerabilities, when exploited together, would result in a much higher CVSS score if a single score could be applied to multiple vulnerabilities. This is what we refer to as an “exploit chain”.
Now, here’s the fun part! Microsoft doesn’t reliably issue advisories for “low risk” vulnerabilities. It’s hard to prove that definitively but there is more than enough evidence to make my case. If Microsoft only publishes advisories for a very small amount of ‘low’, and then “medium” (generally CVSS 5.0+ in any framework) or higher, then what about the rest of those “low” findings? Does it matter if they might be used in an exploit chain? No. That’s a solid, firm, very clear, NO historically. And as best I know, still a no, apparently not important to Microsoft.
So let’s look at the evidence from a few vantage points.
Evidence #1
First, let’s sample recent advisories and MSRC’s CVSSv3 scores to see what the lowest we can find is for any given month. Note the yellow highlight which shows how rarely an advisory is issued for a vulnerability that MSRC scores below 3.0:
That is a very small number of months with a score below 3.0, the last being October, 2025 and January, 2025 before that. I think it is fair to say that most people that work with MSRC data can firmly say that is statistically unlikely. For April, 2026, one advisory / CVE was later REJECTED meaning the score is 0.0, so that was excluded from the data in column C.
Evidence #2
Piggybacking off the above, the obvious counter-argument to that would be “how many possible vulnerabilities can there be with a CVSSv3 score under 2.1? Great question! Ignoring a 0.0 score, meaning no impact to confidentiality, integrity, or availability, the breakdown of CVSSv3 scoring combinations (e.g. AV:L/AC:H/PR:H/UI:R/S:U/C:N/I:L/A:N) is as follows:
| 1.8 | 3 |
| 1.9 | 3 |
| 2.0 | 3 |
| Total | 9 |
Oh no, did I just destroy my own argument? With so few possibilities perhaps they are just not the vulnerabilities that Microsoft products are prone to have. On the other hand, it is illustrative to carry that chart forward and then compare back to the prior evidence and look at months in particular with their lowest CVSS score like March, 2026 (5.3), May, 2024 (5.4), and Jun, 2022 (5.3). Then jump to September and October of this year where we see the vulnpocalypse firmly in action and note the lowest scores are 3.5 and 4.2. Let’s use 3.5 as our new threshold because with the number of disclosures going up that much, logic says that there should be some CVSS scores represented below that.
| 2.2 | 3 |
| 2.3 | 6 |
| 2.5 | 12 |
| 2.7 | 3 |
| 2.8 | 9 |
| 2.9 | 6 |
| 3.0 | 3 |
| 3.1 | 3 |
| 3.2 | 8 |
| 3.3 | 9 |
| 3.4 | 3 |
| Total | 65 |
Now we get a good picture of just how many possible vulnerabilities could exist with a CVSSv3 score below 3.5, yet none are represented in the two biggest months of disclosures by Microsoft. I personally can’t buy that as a fact. Instead, I think those security patches fixed a number of low-risk vulnerabilities and they did not have an accompanying advisory. You can see all of the possible string values for the scores in the table below:
The most compelling argument of this evidence is what CVSS string is not present at all in September or October:
AV:L/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N
That is a local, low access complexity, low privileged partial confidentiality issue where the scope is not changed. Basically, a local information disclosure vulnerability, just like the memory layout example I used earlier in the blog. If anyone wants to argue that it is likely that none were fixed, then I will firmly retort that Microsoft opted not to fix them then.
Between those two pieces of evidence, I hope readers will agree that comparing Microsoft month-to-month just isn’t reliable. It requires too many assumptions and a serious lack of data to do it, thus my point that such comparisons must come with a lot of disclaimers. If you want to compare past November, 2020, that too has a serious issue as Microsoft rarely provided a CVSS score before then.
Convoluted Reasons
Other than the workload required to publish an advisory for literally every vulnerability fixed, we can look to Microsoft’s own documentation that helps weakly try to explain this. That said, it doesn’t make a lot of sense and is contradictory so we’re left wondering why MSRF operates this way. Let’s begin with their “Security Update Severity Rating System” which qualifies what they see as critical, important, moderate, and low with regards to the “worst theoretical outcome” and advice on patching. For “Low”, specifically:
Impact of the vulnerability is comprehensively mitigated by the characteristics of the affected component. Microsoft recommends that customers evaluate whether to apply the security update to the affected systems.
This seems contradictory to itself. There is a low risk, meaning there is some level of risk, and at the same time that risk is “comprehensively mitigated“. I’ve linked to the definitions because while “mitigated” does not mean “fully”, the adverb “comprehensively” does. The second sentence is also problematic because as established above, there is a near guarantee that MSRC patches low-risk vulnerabilities yet won’t publish a corresponding advisory. That means customers aren’t given the opportunity to make a decision due to the lack of information provided.
Jumping back once again to an example of a low-risk vulnerability that is increasingly required in recent exploit chains is an “ASLR Bypass”. Address Space Layout Randomization (ASLR) is a form of defense-in-depth to make exploitation generally more difficult. Being able to bypass it means an exploit might be effective at all or more effective so it is more reliable to work. Microsoft calls this a Security Feature Bypass (SFB) and “Low” risk. An example can be seen in CVE-2015-6088 with the associated language. Interestingly enough, 2018 is the last time we have an explicit “Microsoft .. ASLR Bypass” in a title, which is a byproduct of Microsoft becoming more vague in their advisories since then and researchers often not spelling out details in their own advisories.
In the last Patch Tuesday release (October), there were ~270 vulnerabilities that had an information disclosure impact but due to Microsoft’s vague wording we don’t know what type of information that was for any given issue. So very few of the 1,598 vulnerabilities fixed in that release specifically mention memory disclosure either. The odds of at least a few other unspecified information disclosure having a memory disclosure impact are pretty high. The odds of Microsoft patching vulnerabilities with that impact while not publishing an advisory are also quite high in my opinion, and based on the evidence presented.
Conclusion
While many security professionals like to use Microsoft for vulnerability stats, especially recently in the context of the vulnpocalypse, they almost invariably aren’t a good assessment of what is going on. Due to a lack of knowledge around how MSRC operates, how the advisories have changed over time, and MSRC’s reluctance to issue advisories for low-risk findings, there is no accurate way to talk about the actual number of vulnerabilities they fix any given month. To then compare month to month, when there are many other factors that may be at play, just doesn’t convey meaningful comparisons and data.
If you want to continue comparing any vendor that has a large spike in disclosures this year, start by disclaiming your vulnerability statistics and charts; it is the only way for them to have real value. Be very careful on using “CVE IDs” versus “advisories” versus “vulnerabilities” because those are not a 1:1 comparison often enough. One advisory or CVE ID may represent two or more vulnerabilities. In the case of Microsoft, one advisory is now written to cover one CVE ID, but if a high risk vulnerability was patched alongside a low-risk memory disclosure vulnerability and only the former got an advisory? You’re back to the problem if you aren’t careful.
Leave a Reply