1,413 flaws in one month: Is Windows getting worse, or is AI just finding more?

What this is about

On October 13, 2026, Microsoft fixed 1,413 security vulnerabilities on Patch Tuesday, according to its own release notes. These are CVEs: officially registered, numbered vulnerabilities. That's a record. Before the summer, no Patch Tuesday had included more than about 200 CVEs. On November 5, Nuno Costa, Partner Director for Windows Servicing and Delivery, responded on the Windows blog to concerns that the system is getting more and more full of holes:

"A higher number of CVEs does not mean Windows has become less secure."

Microsoft's explanation: AI tools scan more code more thoroughly and find bugs that have been sitting there for a long time. We checked that claim against numbers that don't come from Microsoft. Here's our argument: Microsoft is largely right about the finding part. But the bottleneck has moved. It now sits in reviewing, fixing and, above all, installing the updates.

The curve: from 100 to more than 1,400 a month

The exact October count depends on who's counting. Tenable and Vicarius get 1,407, BleepingComputer 1,411. BleepingComputer only counts what was released on Patch Tuesday itself and leaves out 348 cloud and early fixes. The Zero Day Initiative gets 1,415. The New York Times reported 1,461, but it counts "patches" rather than CVEs. According to WindowsForum, even Microsoft's own figures don't match: the release notes say 1,413, while the breakdown by product adds up to 1,414.

None of that changes the trend. The monthly series from Vicarius and the Windows-only figures that IT之家 and Windows Latest published based on Microsoft data tell the story:

Do the math: from January to May, the average was about 105 CVEs a month. That matches the "about 100" Cisco Talos cites. July through October alone added up to 3,341. Something else stands out: in January and February 2026, Windows actually had fewer flaws than the year before. The jump only starts in the spring. Talos links it to AI models tuned specifically for vulnerability hunting from around April 2026, including Anthropic's Mythos. According to Windows Latest, Microsoft's own AI scanner, MDASH, uses Mythos alongside in-house models.

Found isn't exploited: what the KEV numbers say

If Windows really had become less secure, attacks should be rising too. The best public yardstick for that is the KEV catalog from the US agency CISA. KEV stands for "Known Exploited Vulnerabilities." A flaw only makes the list if there's evidence of real-world attacks.

Cisco Talos compared the two. CVEs rose 105% year over year, new KEV additions 37%. Of 975 Microsoft advisories in September, just 3 were exploited in the wild, or about 0.3%. In October, according to CrowdStrike and BleepingComputer, it was exactly one of 1,413: CVE-2026-96951, a Windows Shell flaw that lets attackers bypass download warnings.

We did a rough count of the KEV catalog ourselves. On November 4, it had 1,768 entries. At the end of 2025, it had 1,484, according to SecurityWeek and heise. That works out to about 284 additions in 2026, assuming no entries were removed. In all of 2025, there were 245. So the number of exploited flaws is growing noticeably, but on a completely different scale from the number of flaws being found.

Critical vulnerabilities haven't exploded either. According to CrowdStrike, they fell from 113 in September to 75 in October, even as the total rose 45%. Dustin Childs of the Zero Day Initiative sums it up:

"Volume isn't really the story anymore. What matters is that discovery is growing faster than exploitation."

Is AI making the code worse?

That leaves a second worry: does AI-generated code introduce new bugs of its own? A writer on Habr benchmarked the .NET libraries from version 6.0 through 11 RC: 46 operations across dependency injection, configuration, logging, caching and EF Core, with 30 measurement runs each. By the end of October, the Copilot agent had opened 1,734 pull requests (proposed code changes) in the dotnet/runtime repository. 1,207 of them were merged. The result: the biggest slowdown in 11 RC comes from a single line written by a human. It makes a configuration binding take about 145 microseconds instead of 61. The second, smaller regression traces back to a Copilot PR that fixed a deadlock (a state where parts of a program block each other). It costs about 0.9 microseconds per first call.

The author only concludes that there are "no signs" of AI making the code worse in the areas tested, but no proof of the opposite either. It's also worth noting that the benchmark measured speed, not security. On the question of new vulnerabilities, it's weak evidence at best. We found no independent studies on the security of AI-written code in Windows.

The new bottleneck: review, fix, deploy

When finding bugs gets cheap, the pressure shifts downstream. You can see it in several places:

• Linux kernel: According to Phoronix, kernel versions 6.9 through 6.19 each had about 500 CVE fixes per release. Linux 7.0 had more than 1,000, Linux 7.2 more than 1,500. Version 7.3 is expected to top 2,000. Tom's Hardware quotes maintainers who feel "completely overwhelmed." Phoronix notes that most findings are low priority and often sit in old, rarely used drivers.
• Open source in general: Since October 1, Google has stopped accepting new product vulnerabilities for its open-source bug bounty program, OSS VRP, likely until at least the first quarter of 2027. Google cites a flood of automated reports, "the vast majority" of which it says are invalid. It hasn't published any numbers. curl had already shut down its bug bounty at the end of January.
• The AI labs' patches: According to CyberScoop, OpenAI's Daybreak website reports 661 patches created and tested, of which maintainers accepted 458. That's about 69%. It's unclear whether the remaining 31% were rejected or are still under review. OpenAI's Michael Aiello admitted that some maintainers simply won't "respond to hundreds and hundreds of AI-reported vulnerabilities."
• Companies: According to HackerOne, the backlog of confirmed but still open vulnerabilities on its platform has grown 131% in two years, even though the average time to fix has more than halved, from 135 to 62 days. CEO Kara Sprague: "The bottleneck is no longer discovery. It's everything between a report coming in and the risk being eliminated."

The clearest evidence comes from Microsoft itself. Based on diagnostic data from a sample of enterprise devices, fewer than half had installed the update two weeks after the August Patch Tuesday. After four weeks, it was still missing on about one in four devices. According to Windows Latest and IT之家, Microsoft now advises against deferring monthly updates for more than three days. In the blog itself, that limit mainly shows up in the Intune dashboard, where a device counts as "Exposed" after about three days without the update. WindowsForum pushes back, arguing that many companies test updates first for good reason. A patch that breaks a business application makes admins more cautious the next time around.

The window is shrinking to hours

The delay is dangerous because attackers can now use AI to analyze published patches. In June, Anthropic tested how fast that works: Mythos Preview generated a proof of concept (a demonstration that the flaw can actually be triggered) for 18 of 21 Windows kernel patches. The first was ready after 31 minutes, all 18 after six hours. On top of that came eight complete attack chains to system privileges, at about $2,000 each. Anthropic's math: with Windows Autopatch, a patch reaches 90% of devices after about seven days, and the forced restart comes on day 11. So the attacks would have been ready before the first device was protected. Anthropic itself points out that a real attack takes more steps, such as finding targets and staying undetected.

"Black October" at PHP showed what this looks like in practice. The first report of the flaws came in on August 11, and the patched versions shipped on October 21. That's 71 days for a fix that touched about 200 files, according to Business Model Analyst. Because details leaked early, Cloudflare counted thousands of attack attempts 10 hours before disclosure. Forty-five minutes after, it was tens of thousands, and after about 12 hours, millions. For context: there's no evidence yet of successful mass compromises. According to The Hacker News, Previdian, SOCRadar and Hunt.io found no successful code execution, and Sophos observed that attackers struggled to build reliable exploits.

Our take

In our assessment, Microsoft's core claim is well supported by the independent data. When CVEs rise 105% but KEV entries only 37%, exploited zero-days stay in the single digits per month, and critical flaws actually decline, that fits a backlog of old bugs being cleared. It doesn't fit a Windows that's suddenly been coded worse. To be honest, though, it also means these flaws were already in the code. Windows was never as secure as the old numbers suggested.

Some things remain unproven. Microsoft hasn't said how many of the October flaws MDASH found, and it hasn't presented a controlled before-and-after comparison. The installation data comes from a sample. t3n reports Microsoft's claim that the number of exploited flaws in 2026 fell compared with the first nine months of the previous year. We couldn't find numbers to back that up. Nor has anyone verified that AI code doesn't hurt security. The Habr benchmark only covers speed.

The theory can still be tested. Talos points to earlier bug classes, such as format string bugs, that spiked and then faded. If Microsoft's monthly numbers drop back to a few hundred by mid-2027, that points to a backlog being cleared. If they stay above a thousand, that's the new normal.

Whatever the answer, if you're a user or admin, one thing holds: a fixed flaw only protects you once the update is installed. On November's Patch Tuesday, installing quickly matters more than how many CVEs are on the list. Microsoft says to prioritize internet-facing systems, identity infrastructure (such as Active Directory) and high-value machines. The "less secure or not?" question distracts from the real risk: the time between a patch and an attack is now shorter than the time most organizations need to patch.