974 CVEs in One Patch Tuesday: AI Made Finding Bugs Cheap. Fixing Them Is Now Your Bottleneck.
Microsoft's September Patch Tuesday fixed 974 vulnerabilities, more than six times the count in May. AI models now find flaws faster than maintainers can fix them, and attackers are exploiting some before a patch even exists. Meanwhile, the median time to patch has gone up. Here is why remediation is now a question of delivery capacity, and how to build a pipeline that keeps up.
The Month the Patch Count Broke
For most of the last decade, a Microsoft Patch Tuesday meant somewhere between 50 and 120 vulnerabilities. That stopped being true this year. In June, Microsoft broke its own record with 206 CVEs, beating the previous high of 175 from October 2025. Security researchers told reporters that the days of 50 to 70 CVEs a month were over. They were still underestimating what was coming.
On September 8, Microsoft patched 974 vulnerabilities in a single release. That included two zero-days already under active exploitation and 20 flaws that SecurityWeek described as potentially wormable. Windows alone accounted for 723 of them, Office for 222 and SQL Server for 62. According to The Cyber Express, the monthly totals this year went from 161 in May to 220 in June, 663 in July, 457 in August and then 974 in September.
The explanation that keeps coming up is AI-assisted vulnerability discovery. Tenable's Satnam Narang gave the most useful version of it to SecurityWeek: "AI-assisted vulnerability discovery in 2026 is creating larger haystacks, but isn't finding more needles." Put another way, most of the new CVEs will never be exploited, but every one of them still has to be read, triaged and either patched or deliberately accepted by somebody.
This is not only a Windows administrator's problem. If you build and ship software, the same trend reaches you through your operating systems, runtimes, frameworks, container base images and every open-source library in your lockfile. The volume of fixes you need to absorb has grown sharply this year. The key question is whether your engineering organisation can absorb it without either stopping feature work or quietly falling behind.
Discovery Became a Commodity in About Eighteen Months
The speed of the change is hard to overstate. CERT-EU's analysis of AI and vulnerability discovery brings the evidence together. On CVE-Bench, the best autonomous agents went from exploiting 13% of test vulnerabilities to 90% in less than a year. In DARPA's AI Cyber Challenge, seven finalist teams found 54 vulnerabilities across 54 million lines of code in four hours, at roughly $152 per task. An autonomous system from AISLE found all 12 CVEs in OpenSSL's January 2026 release.
Then came the frontier labs. In April, Anthropic introduced Claude Mythos Preview together with Project Glasswing, a programme that gives critical-software maintainers access to the model. By late May, Anthropic reported more than 10,000 high- or critical-severity vulnerabilities found across partner systems. A scan of over 1,000 open-source projects produced 23,019 findings, 6,202 of them rated high or critical. When Anthropic and six independent security firms reviewed 1,752 of those findings, more than 90% were confirmed as real. CERT-EU notes that on one Firefox exploitation test, Mythos Preview produced 181 working exploits where the previous model managed two.
Other labs are close behind. OpenAI launched GPT-5.6 Cyber in August through a gated tier of its Daybreak programme for partners such as CrowdStrike and Cloudflare, and warned that "threat actors will increasingly use AI to conduct cyberattacks at unprecedented speed and scale, including in fully autonomous ways." Open-source replications of agentic vulnerability-discovery scaffolds already exist and run for about a dollar per scan on publicly available models.
The most important line in Anthropic's update is not a statistic, though. It is this admission: "The relative ease of finding vulnerabilities compared with the difficulty of fixing them amounts to a major challenge for cybersecurity." Anthropic said open-source maintainers had become the main constraint, and it partnered with the OpenSSF's Alpha-Omega project to help them cope. Finding bugs now scales with compute. Fixing them still scales with engineers.
Key Takeaways
- Best autonomous agents on CVE-Bench went from 13% to 90% exploitation success in under a year
- AIxCC finalists found 54 vulnerabilities in 54 million lines of code in four hours, at about $152 per task
- Project Glasswing produced 10,000+ high or critical findings in about a month, with a 90%+ true-positive rate
- Anthropic's own conclusion: discovery is now easy, and fixing is the bottleneck
The Window Is Closing From Both Sides
If attackers were still slow, a larger backlog would just be a larger to-do list. They are not. CERT-EU, citing Mandiant data, reports that the mean time to exploit a newly disclosed vulnerability has fallen to an estimated minus seven days. In 2018 it was 63 days. On average, exploitation now begins before the fix ships. CERT-EU sums it up in a sentence worth sharing with your leadership team: "The traditional cycle of discover, disclose, patch, deploy was designed for a slower adversary. That adversary no longer exists."
Defenders, meanwhile, got slower. According to Help Net Security's summary of the 2026 Verizon DBIR, the median time to patch rose from 32 to 43 days, and only 26% of vulnerabilities in CISA's Known Exploited Vulnerabilities catalogue were fully remediated, down from 38% a year earlier. Organisations named the sheer volume of vulnerabilities as their main problem. For the first time in the report's 19-year history, exploiting a vulnerability overtook stolen credentials as the most common way a breach begins. SecurityWeek put its share at 31% of breaches.
The browser vendors have already acted on this. Within about ten days, Chrome, Edge and Firefox all moved from four-week to two-week release cycles. Chrome 153 on September 8 was the first on the new schedule, and Google said it now uses Gemini-powered tools to find and fix vulnerabilities. Companies that ship software to billions of users decided that a monthly release could no longer absorb the flow of security fixes. It is worth asking whether your product is on a faster cadence than theirs.
Put these numbers side by side and the problem becomes clear. Exploitation is measured in hours or days, while remediation is measured in weeks and is getting slower. The gap between them is where breaches happen, and a better scanner cannot close it. Only a faster path from finding to fix to deployment can.
| Measure | Earlier | 2026 | Source |
|---|---|---|---|
| Mean time to exploit | 63 days (2018) | About minus 7 days | CERT-EU, citing Mandiant |
| Median time to patch | 32 days | 43 days | Verizon DBIR 2026 |
| Known exploited vulnerabilities fully remediated | 38% | 26% | Verizon DBIR 2026 |
| Largest Microsoft Patch Tuesday | 175 CVEs (Oct 2025) | 974 CVEs (Sep 2026) | SecurityWeek, CyberScoop |
| Major browser release cadence | Four weeks | Two weeks | Engadget |
Read the Numbers Carefully Before You Panic
A flood of CVEs creates a new risk of its own: treating every one of them as urgent, burning out the team and missing the few that matter. The more careful data shows why prioritisation now matters more than raw speed. VulnCheck's State of Exploitation report for the first half of 2026 counted 495 newly known exploited vulnerabilities. It found that 23.43% were exploited on or before the day the CVE was published, down from 28.93% in 2025.
VulnCheck also looked at the AI-found vulnerabilities specifically. Of 1,061 vulnerabilities it attributed to AI-assisted discovery, only 14, or 1.3%, had been confirmed as exploited in the wild. Of Project Glasswing's 23,019 findings, one had been confirmed as exploited. VulnCheck's conclusion is balanced: AI-assisted discovery is valuable to both attackers and defenders, but so far AI-found bugs are exploited at about the same rate as bugs found in traditional ways. This matches Narang's point about larger haystacks without more needles.
Where exploitation does happen, it is concentrated. VulnCheck found that content management systems accounted for a third of all known exploited vulnerabilities, driven largely by WordPress plugins, with security tools, developer platforms and device management systems also exploited quickly. If your business runs on an internet-facing CMS, an admin panel or a self-hosted developer platform, you are in the part of the distribution that attackers target first.
The practical lesson is to split the work into two lanes. The small set of vulnerabilities that are known to be exploited, reachable in your code and exposed to the internet needs a fix in days or hours. Everything else needs a steady, automated flow of updates so it never piles up into a backlog that hides the next urgent one. Treating everything as urgent fails, and so does treating everything as routine.
Key Takeaways
- 23.43% of known exploited vulnerabilities in 1H 2026 were exploited on or before disclosure day
- Only 1.3% of AI-discovered vulnerabilities have been confirmed as exploited so far
- One third of known exploited vulnerabilities were in content management systems
- Use two lanes: emergency fixes for exploited, reachable and exposed flaws, and routine automated updates for everything else
Remediation Is a Delivery Capability, Not a Security Ticket
In most organisations, a vulnerability starts as a ticket from the security team to an engineering backlog. There it competes with feature work, waits for a sprint and ships with the next release. That process was built for a world with a few dozen relevant CVEs a month and exploits that took weeks to appear. It cannot handle ten times the volume with exploits that arrive in hours.
How fast you can patch depends on three things that have little to do with security tools. The first is how current your dependencies are. Moving one minor version is a routine update. Moving four major versions of a framework is a project, and nobody can finish a project in 48 hours. Teams that let dependencies drift turn every urgent CVE into a migration. We have seen this with .NET, Python and PostgreSQL upgrades this autumn.
The second is test coverage. You can only merge a dependency update quickly if you trust your test suite to catch what it breaks. Without that trust, every patch needs manual regression testing, and manual testing is the stage that has lost the most capacity this year, as we described in our piece on the verification gap. AI can write a candidate fix in minutes. It cannot tell you whether that fix breaks your invoicing flow unless a test does.
The third is deployment lead time. If a production release needs a change advisory board, a weekend window and three people who know the old deployment script, then your time to patch can never be shorter than your release cycle, however quickly the fix is written. The DORA metric for lead time for changes is now, in practice, also your minimum exposure window. Speeding up delivery and reducing security exposure have become the same work.
What a Remediation Pipeline Looks Like in 2026
The teams handling this year well have not hired a large security department. They have made fixing vulnerabilities a normal, automated part of how they ship. The building blocks are well known. What is new is that they have moved from nice-to-have to necessary.
Start with an accurate inventory. You cannot prioritise what you cannot see, so generate a software bill of materials for every build and every container image, and keep it queryable. When a critical CVE lands, you should be able to answer "where do we run this, and in which version?" in minutes, not with a spreadsheet exercise. Under the EU Cyber Resilience Act, this inventory is also the starting point for the reporting obligations that began on September 11.
Then prioritise using exploitation data, not only CVSS scores. Combine CISA's Known Exploited Vulnerabilities catalogue, exploit prediction scores such as FIRST's EPSS, and reachability analysis that checks whether the vulnerable function is actually called by your code. A critical score on a library function you never call is less urgent than a medium score on your login endpoint.
Next, automate the routine lane fully. Dependency update bots should open small pull requests continuously, CI should run the full test suite on each one, and low-risk updates that pass should merge with minimal ceremony. This is where AI coding agents are genuinely useful on the defensive side: drafting fixes for breaking API changes, updating call sites and writing the missing regression test. A human engineer still reviews and owns the change. Finally, set explicit service levels and measure them. For example, known exploited and internet-facing vulnerabilities might be fixed within 72 hours, other criticals within 14 days and everything else within the next regular release. Report time to remediate next to your delivery metrics, because the two now describe the same system.
Key Takeaways
- Generate an SBOM for every build so any CVE can be located in minutes
- Prioritise with KEV, EPSS and reachability analysis, not CVSS alone
- Automate routine dependency updates end to end, and let AI draft fixes that engineers review
- Set remediation SLAs by exposure and track them next to delivery metrics
Your Suppliers Are in the Same Window
Your exposure does not end at your own repositories. The 2026 DBIR found that third-party involvement in breaches rose 60% year over year and now accounts for close to half of all breaches, and that third parties were slow to fix even basic problems. Only 23% fully resolved MFA issues, and permission misconfigurations took close to eight months to fix. Every agency, SaaS provider and development partner that ships code into your environment has the same remediation problem you do, and in many cases less capacity to deal with it.
Regulation is starting to reflect this. The Cyber Resilience Act requires manufacturers of products with digital elements to report actively exploited vulnerabilities within 24 hours, and NIS2 is pushing security obligations down the supply chain through contracts, as we covered in our article on NIS2 flow-down clauses. If a partner built your product, their patching speed is now part of your compliance position.
So ask your software suppliers the same questions you ask yourself. How current are the dependencies in the code they maintain for you? Is there an SBOM for every release? What remediation SLAs do they commit to, and can they show their actual numbers? How long does it take them to go from a merged fix to production? A vendor that cannot answer clearly is telling you how your next critical CVE will go.
This also affects the code nobody is responsible for anymore. Many companies run applications that an agency delivered years ago and nobody has touched since. Those systems have not had their dependencies updated, have no tests and have nobody on call, and in a world of AI-driven discovery they are the easiest targets you own. Finding them and assigning someone to maintain them is one of the highest-value security tasks you can do this quarter.
How Stepto Helps Teams Close the Gap
At Stepto we see the patching problem from the engineering side, because that is where it gets solved. Our dedicated development teams build remediation into normal delivery. We generate SBOMs in CI, run automated dependency updates behind real test suites, prioritise by exploitability rather than raw severity, and keep deployment pipelines fast enough that an urgent fix can reach production in hours. When a record Patch Tuesday lands, our clients get a short list of what matters to them and a plan with dates, not a spreadsheet with a thousand rows.
Much of the value is in the unglamorous work that in-house teams rarely have time for: bringing a drifted framework back to a supported version, adding the missing test coverage that makes safe upgrades possible, and taking ownership of legacy applications that nobody currently maintains. That work reduces your exposure more than any new scanner, and it is exactly what a steady, senior nearshore team is good at.
The nearshore model matters here in practical ways. Our engineers in Serbia work in Central European Time, the same working day as European clients and with a shared window of several hours with US East Coast teams. An exploited vulnerability disclosed in the morning can be triaged, fixed, reviewed and deployed together on the same day, instead of being passed across time zones overnight. Because we operate under GDPR and are familiar with the CRA and NIS2, we can support the reporting and supplier-assurance requirements that now come with every serious incident.
If your backlog is growing faster than your team can close it, nearshore development with Stepto gives you added engineering capacity focused on the work that shrinks your exposure window: dependency modernisation, test automation, CI/CD speed and a remediation process you can measure. AI has made vulnerabilities cheap to find. We help make sure they are also quick to fix.
Your Patch Speed Is Now Your Security Posture
In 2026, AI turned vulnerability discovery from a scarce skill into an inexpensive, scalable process, available to defenders and attackers alike. Patch volumes have grown more than sixfold in four months, exploitation often starts before fixes are released, and the average organisation is patching more slowly than it did a year ago. More scanning will not fix that gap. What fixes it is engineering: current dependencies, tests you trust, fast deployment pipelines, prioritisation based on real exploitability, and suppliers who hold themselves to the same standard. The organisations that treat remediation as part of how they deliver software will absorb the next record Patch Tuesday as routine work. If you want help building that capability, Stepto's dedicated development teams can work alongside your engineers to shorten your exposure window and keep it short.
Building a team in Eastern Europe?
StepTo helps European and US companies build senior-led nearshore engineering teams in Serbia. Let's talk about what your next engagement could look like.
Start a conversationMore from StepTo on this topic
- Your Sprints Are Faster. Your Releases Aren't. Here's Why AI Coding Tools Are Hitting a Wall
AI tools made a coding task 55.8% faster in a controlled trial, yet team delivery has not kept pace. The delivery paradox has a specific, fixable cause.
- Writing the Code Got Cheap. Landing It Did Not. What a Fleet of Coding Agents Actually Costs to Run
Stripe merges 1,300 agent-written PRs a week. Most teams that copy the fleet find the bottleneck moved to review, merge conflicts and CI spend.
- The Maintainers Are Leaving: What the AI Slop Flood Means for the Code You Ship but Didn't Write
curl shut its bug bounty, Ghostty banned drive-by AI pull requests, tldraw auto-closes external contributions. Meanwhile 93% of commercial codebases contain components nobody has touched in two years. These two facts are the same fact.
Written by
Igor GazivodaFounder & CEO · StepTo
Igor has 15+ years in software engineering and business development. He specializes in scaling engineering teams, nearshore strategy, and AI-driven product development. He holds a Master's in Computer Science from the University of Belgrade.
LinkedIn →