# Microsoft's own CVE count is up nearly eightfold in a year

2026-10-14

Microsoft-assigned CVEs rose from 180 to 1417 a month in a year, and the monthly release keeps growing after Patch Tuesday.

Microsoft shipped its October security update on 13 October 2026. Depending on who you read, it fixed 1407, 1411 or 1417 vulnerabilities. They count different things, and the difference matters more than it used to.

I pulled the same machine-readable document Microsoft publishes for every month, the CVRF file behind the Security Update Guide, on 14 October at 11:04 UTC. The October document lists 1760 CVEs. Each entry names the CVE Numbering Authority that assigned it, and Microsoft is the assigning authority on 1417 of them. The rest were assigned by others, mostly Linux kernel and Apache CVEs that Microsoft republishes for Azure Linux packages.

## The series, counted one way

Here is every month I pulled, restricted to CVEs Microsoft assigned itself.

| Baseline month | Microsoft-assigned CVEs |
| --- | --- |
| 2024-07 | 144 |
| 2025-01 | 165 |
| 2025-04 | 132 |
| 2025-07 | 137 |
| 2025-10 | 180 |
| 2026-01 | 124 |
| 2026-02 | 61 |
| 2026-03 | 97 |

| Recent month | Microsoft-assigned CVEs |
| --- | --- |
| 2026-04 | 181 |
| 2026-05 | 162 |
| 2026-06 | 220 |
| 2026-07 | 663 |
| 2026-08 | 456 |
| 2026-09 | 998 |
| 2026-10 | 1417 |

The baseline months average 130. October 2026 is 10,9 times that, and 7,9 times October 2025. Leave out February, the low outlier, and the average is 140 and October is 10,1 times it.

Severity did not drop as volume rose. In July 2025 the median CVSS base score of Microsoft-assigned CVEs was 7,8, and in July 2026 it was still 7,8, with 76,6 % and 74,2 % of them at 7,0 or above. Critical-rated CVEs went from 17 to 77. October looked similar: the median went from 7,3 to 7,5, and Critical-rated CVEs from 18 to 76. The bigger releases contain more of the same kind of finding, not a pile of minor ones.

## The release is not a fixed list

The monthly document does not stay the size it was on Patch Tuesday. Today the July 2026 document holds 2005 CVEs. Of those, 874 first appeared after 14 July, most of them Chromium CVEs for Edge and Linux CVEs for Azure Linux. In September, 1595 of 2776 entries arrived after Patch Tuesday. CVEs first published on Patch Tuesday itself are 27 % of today's April document, 29 % of July and 36 % of September.

So "the July release" read on release day and the same document read three months later differ by hundreds of entries. A count or a patch list without a pull date does not say which entries it contained.

## What Microsoft itself says about the load

On the day of the release MSRC published a post about how customers can cope with large releases. It does not give a cause for the record. It proposes what it calls risk cohorts: group the CVEs that raise the same question about your environment, answer that question once and write the answer down, then review each CVE with that context. Its examples are questions like whether an RD Gateway is reachable from outside the corporate network, or which users open untrusted documents and mail.

Microsoft is careful with it. The post calls the cohorts exploratory and says they do not change Microsoft's update guidance or replace the review of each CVE. Its one line about AI ties the approach to AI-assisted discovery: "As AI-assisted research contributes to vulnerability discovery", this kind of grouping may become more useful. It does not say how much of this month's count that explains.

That is as far as Microsoft's own October text goes. BleepingComputer attributes the record to Microsoft's use of AI platforms in its own voice, with no source cited in the text. In July the head of Windows wrote that customers would see higher update volume as AI helps defenders find more issues, which I measured [in an earlier post](/blog/measuring-the-ai-patch-surge). This post measures the count. It does not prove the cause.

## The one that had a deadline

One October CVE was already exploited: CVE-2026-96951, a Mark of the Web bypass in Windows Shell rated CVSS 8,8. CISA added it to its Known Exploited Vulnerabilities catalog on 13 October with a due date of 16 October.

The CVE with a CISA due date three days out arrived in the same release as 1416 other Microsoft-assigned CVEs. Finding it in the list is easy, because it is flagged. Deciding what comes next for the rest is the slow part, and that part depends on facts about your own environment that no feed contains.

## If a script or an agent does the triage

Handing patch triage to automation is the obvious response to a release this size, and two inputs decide whether it works.

The first input is the feed. It changes after you read it, so the pull time and the document revision belong with every decision made from it. An agent that triaged the July document on release day and another that triaged it in October worked from different lists, and both were correct about what they were given.

The second input is the answers. Whether the RDP gateway is exposed, which roles are deployed and who opens outside documents are facts about one organisation. If they are written down and kept current, an agent can apply them to 1417 CVEs consistently. If they are not, the agent fills the gap with a guess, and nothing in its output will show which answers were guessed.

That second input is the part I work on: the data an agent acts on and the limits of what it may decide on its own.

## A correction to my July post

[The July post](/blog/measuring-the-ai-patch-surge) counted every CVE in each monthly document, including the ones other authorities assigned. Counted that way, July 2026 was 3,0 times the baseline. Counted as Microsoft-assigned only, the rise is steeper: July 2026 is 5,1 times the baseline of 130. The severity comparison does not survive the narrower count. The July post reported the median moving from 6,5 to 7,5. For Microsoft-assigned CVEs it stayed at 7,8. The shift in that post came from the mix of CVEs in the documents, not from Microsoft's own findings. A dated note on that post now says so.

## Check it yourself

    https://api.msrc.microsoft.com/cvrf/v3.0/cvrf/2026-Oct

Send an Accept: application/json header. The Vulnerability array is the full list. In each entry, the note with Type 8 names the assigning authority, the earliest RevisionHistory date is when the CVE first appeared in the document, and Threats with Type 3 carries the severity rating. Change the month to pull another. Your counts will differ from mine if Microsoft has revised the document since 14 October, which is the point of the second section.

## Frequently asked

**Why do outlets report different CVE counts for the same Patch Tuesday?**

They count different sets. Some count only the CVEs released on Patch Tuesday itself, some count every CVE Microsoft assigned that month, and the monthly CVRF document also lists CVEs other authorities assigned for Edge and Azure Linux. For October 2026 the news sources give 1407, 1411 or 1417, and the document lists 1760.

**Does Microsoft say AI caused the October record?**

Not in its own October text. The MSRC post published on release day ties its risk cohort idea to AI-assisted research but gives no cause for the record. BleepingComputer credits AI for the record in its own voice.

**How do I count only the CVEs Microsoft assigned itself?**

Pull the month from the MSRC CVRF API with an Accept: application/json header and keep the Vulnerability entries whose note with Type 8 reads Microsoft. Record the pull time with the count, because Microsoft keeps adding entries to the document after release.

## Related

- [Microsoft said the patches would get bigger. I measured how much bigger.](/blog/measuring-the-ai-patch-surge)
- [Define what an agent may do with your data](/guides/letting-agents-act-on-data)
- [Measure agent-readiness with evidence](/guides/measurement-led-agent-readiness)