Microsoft said the patches would get bigger. I measured how much bigger.
2026-07-15
A comparison of selected Microsoft security-update datasets examines changes in reported vulnerability counts and severity, with the comparison limits stated.
On 9 July 2026 the head of Windows published a post about AI-powered vulnerability discovery. One line in it was a warning to customers: "As AI helps defenders discover more issues, customers will see a higher volume of security updates included in each security release."
It does not say how much higher. The post runs well over a thousand words and gives no figure for the increase.
Five days later Microsoft shipped the July package: 1150 CVEs.
The number Microsoft would not put in the blog post is sitting in Microsoft's own API. The Security Update Guide publishes every monthly package as machine-readable CVRF, acknowledgments included, no key required. So I pulled twelve months of it and did the arithmetic.
What the data says
I sampled eight months before the ramp and four after it.
| Month | CVEs | Month | CVEs |
|---|---|---|---|
| 2024-07 | 454 | 2026-04 | 737 |
| 2025-01 | 343 | 2026-05 | 991 |
| 2025-04 | 374 | 2026-06 | 1281 |
| 2025-07 | 527 | 2026-07 | 1150 |
| 2025-10 | 427 | ||
| 2026-01 | 310 | ||
| 2026-02 | 169 | ||
| 2026-03 | 460 |
The eight pre-ramp months average 383 CVEs. July 2026 is 1150, so the package is 3,0 times the old normal. The baseline broke in April and peaked in June at 1281.
April to July inclusive is 4159 CVEs. At the old rate that is 10,9 months of output, delivered in four.
The number I am not going to use
February 2026 had 169 CVEs. It is the lowest month in two years, less than half the baseline. Divide July by February and you get 6,8 times, which is a much better number for a headline.
I am not using it, because choosing your denominator is how honest people produce dishonest numbers. February is an outlier, and the only reason to anchor to it is that it flatters the story. The real multiplier is 3,0. It does not need help.
It is not noise
The obvious objection is that volume without quality is just a bigger pile. If AI were generating low-value findings that got patched anyway, the severity distribution would sag. It did the opposite.
| Measure | 2025-07 | 2026-07 |
|---|---|---|
| CVEs | 527 | 1150 |
| CVSS median | 6,5 | 7,5 |
| CVSS mean | 6,47 | 7,26 |
| CVSS 7,0 and above | 48,0 % | 71,9 % |
| CVSS below 4,0 | 4,2 % | 0,8 % |
| Rated Moderate | 33,4 % | 4,8 % |
| Rated Critical | 26 | 66 |
| Remote code execution | 42 | 165 |
| Elevation of privilege | 58 | 256 |
More than twice the volume of the same month a year earlier, and the median CVE is a full point more severe. The Moderate band collapsed from a third of the package to under five per cent. Remote code execution roughly quadrupled.
One caveat, stated plainly. The share of CVEs Microsoft did not assign a CVSS score to rose from 5 % to 38 %. Those are likely Chromium-inherited Edge issues, which Microsoft does not usually score itself. The severity claim above holds for what Microsoft scored. I cannot speak for the rest, and neither can anyone who has not opened the file.
Why the well did not run dry
Windows has been patched for thirty years. Intuition says the supply of findable bugs should be thinning. Instead it tripled.
The explanation is in Microsoft's own May post about MDASH, their multi-model agentic scanning harness. Run against five years of confirmed vulnerabilities in clfs.sys, it re-found 96 % of them. In tcpip.sys, 100 %.
A harness re-found almost everything human researchers took five years to find. The bugs were discoverable the entire time. There were never fewer of them. Nobody was looking hard enough, because looking was rate-limited by human attention rather than by how many bugs were actually there.
The well was not draining. It was being sipped. What we are watching is not a bug explosion. It is a backlog, and the backlog is as old as the code.
This explains capacity. It is not proof of cause. Microsoft's own post attributes the higher volume to AI-assisted discovery. The measurement in this post confirms that the volume rose and puts a size on it. It does not, on its own, prove that AI is the sole or demonstrated cause of that rise, only that the rise coincides with the capability Microsoft describes.
The capability is in the harness
MDASH is over a hundred agents, multi-model debate across model families, and a separate pipeline that proves candidates before a human ever sees them. Microsoft reports it at 88,45 % on CyberGym, a benchmark for real-world vulnerability discovery, in its 12 May 2026 announcement. Anthropic's gated frontier model, Claude Mythos, is reported at 83,1 % on the same benchmark; the same Microsoft post names that figure as the entry just below its own, and GeekWire's coverage attributes it to Mythos.
I am not going to tell you the orchestration layer beats the model. Those two figures come from two different parties. Microsoft names its side of the setup, the CyberGym default level 1 configuration across 1507 tasks from 188 OSS-Fuzz projects, but Anthropic's system card gives only part of its setup for Mythos, pass@1 over the same 1507 tasks with no extended thinking, and does not name the CyberGym difficulty level, so the two scores cannot be assumed to share a setup, and a gap of 5,35 percentage points does not show that either approach is better. What the pair does establish is an order of magnitude: an orchestration layer running an ensemble, distilled models included, lands in the same range as the most capable model anyone has built.
That has a consequence worth sitting with. Access to Mythos is controlled by Anthropic under Project Glasswing. Orchestration is controlled by nobody, and it is described in a public blog post. If the scaffolding carries that much of the capability, the interesting question is not how far open weights trail the frontier model. It is how far an open harness trails MDASH. Scaffolding is cheaper to copy than a frontier model.
The same technology closed a bug bounty
In January 2026 the curl project shut down its bug bounty. Twenty reports arrived in the first twenty-one days of the year, seven of them in one 16-hour window, and none was a real vulnerability, according to Bugcrowd's account of the shutdown. Daniel Stenberg called such reports AI slop. HackerOne reported March 2026 submissions up 76 % year over year, with the share of valid findings steady at roughly 25 % (HackerOne). Google raised the proof it requires in its open-source reward programme after a surge of low-quality reports (Google's rule update). GitHub tightened its requirements.
So in the same six months, one organisation shipped 1150 real CVEs and credited AI-assisted discovery for the rise, and another was driven out of the bounty business by AI reports that were worth nothing.
Same technology. The difference is the prove pipeline. Microsoft built one, with dedicated cloud infrastructure behind it. curl is volunteers, and volunteers cannot fund a filter, so the only move left was to close the door.
Check it yourself
The CVE counts and the severity split above come from one endpoint. No key, no account.
https://api.msrc.microsoft.com/cvrf/v3.0/cvrf/2026-Jul
Send an Accept: application/json header, count the Vulnerability array, read Threats for severity and CVSSScoreSets for the scores. Change the month and run it again. If my baseline of 383 is wrong, the file will say so, and I would rather you tell me than take my word for it.
Note added July 16: one fair objection surfaced when this post was re-read with hostile eyes. The eight-month baseline includes the February outlier, the same kind of number the denominator section warns about. Excluding February, the baseline is 414 and the multiple is 2,8 rather than 3,0. The direction survives either denominator, and now both numbers are on the record.
Note added July 17: this post tells you to run the query yourself, so it owes you the reason your numbers will not match mine. Microsoft keeps revising these documents after release. Re-pulled on 17 July 2026, May 2026 returns 1123 rather than 991, June returns 1205 rather than 1281, and July returns 1169 rather than 1150. The May document is on revision 2275 and June on revision 1141, both last revised on 15 July 2026. The eight baseline months have not moved, so the baseline of 383 stands. On the figures the endpoint returns today, July is 3,1 times the baseline rather than 3,0, April to July is 4234 CVEs or 11,1 months of output at the old rate, and June is still the peak. The table above is what the endpoint returned when I ran it, and the pull date is now part of the number.
Why this matters if you are buying anything
This is the method I sell, pointed at someone else.
A vendor made a qualitative claim: volume will go up. The receipt was public, machine-readable and free the whole time. The gap between the press release and the API was the entire story, and closing it took an afternoon and no privileged access.
That is what measurement is for. Not to catch anyone out. Microsoft's post is accurate, and the data supports the direction it describes more strongly than the post itself does. The point is that "higher volume" and "3,0 times, and the median CVE gained a full point of severity" are different sentences, and only one of them can be checked.
Agent-readiness works the same way. A site can assert it is ready for AI agents. A scanner reads the site and returns a number. One of those is an opinion.
Note added September 27: two sentences went further than the numbers. The severity table compares July 2026 with July 2025, 1150 against 527, which is 2,2 times and not three. Three times is the multiple against the eight-month baseline. The bounty section said the organisation used AI to ship the 1150 CVEs, which is Microsoft's own attribution and not something this post measured, as the capacity section already says. Both sentences now say what this post measured. No CVE count changed.
Corrected 2026-09-28. A sentence said the two benchmark figures came from conditions neither party published. Microsoft's own linked source names its side, the CyberGym default level 1 configuration across 1507 tasks from 188 OSS-Fuzz projects, and the sentence now says that, and that Anthropic's own conditions for Mythos are not published.
Corrected 2026-10-02. Several sentences claimed more than their sources. The Mythos sentence said Anthropic's own evaluation conditions are not published, and the 2026-09-28 note above repeats it. Anthropic's system card publishes the task count, pass@1 scoring and sampling settings but does not name the CyberGym difficulty level, so it now says: "Microsoft names its side of the setup, the CyberGym default level 1 configuration across 1507 tasks from 188 OSS-Fuzz projects, but Anthropic's system card gives only part of its setup for Mythos, pass@1 over the same 1507 tasks with no extended thinking, and does not name the CyberGym difficulty level, so the two scores cannot be assumed to share a setup, and a gap of 5,35 percentage points does not show that either approach is better." The same sentence also said five points is well inside what a difference in evaluation setup can produce, which no cited source quantifies, so it now says the gap does not show either approach is better. The Microsoft post is longer than about 1400 words and carries ordinary numerals, so the sentence now says it gives no figure for the increase. HackerOne's 76 % is March 2026 against March 2025, not a year through March, and HackerOne reports the valid share steady at roughly 25 %, so the noise claim is gone. The three-quarters-noise wording, the DDoS attribution and the claim that Google stopped taking AI-generated submissions are replaced by what the linked sources say.