AI Vulnerability Discovery Is Flooding Patch Advisories, but Exploitation Lags

The sharp rise in vulnerability advisories is a workload problem, but the raw count doesn’t show how many weaknesses attackers can use. AI tools are helping researchers examine old, widely used code at a pace that pushes up disclosure volumes. So far, known exploitation has grown much more slowly.

Microsoft’s September Patch Tuesday included 975 vulnerability advisories. The October release listed 1,415, compared with an average of about 100 per month before June. The source attributes this increase to frontier AI models, including Mythos, becoming more capable of finding known vulnerability types in large codebases.

That shift raises practical questions for software teams: whether the findings are genuinely exploitable, how quickly maintainers can respond, and whether a disclosure process built around a typical 90-day window still fits the pace of discovery. The available figures offer one useful distinction: a disclosed weakness isn’t necessarily a weaponized one.

AI is working through old code

Much of the new volume appears to come from established libraries and tools with long histories of releases. These systems carry technical debt accumulated over many years, and AI-assisted analysis can search that backlog for familiar flaw patterns. The models described here haven’t uncovered a new class of vulnerability; they’re finding known kinds of bugs more efficiently.

That matters because mature software is often deeply embedded in company environments. Its age and broad use can make it a predictable target, while the software itself may be difficult for defenders to inventory. The source points to Log4j as an earlier example: the library was widely deployed, yet some organizations didn’t know it was present until a flaw made that uncertainty urgent. The vulnerability was CVE-2021-44228.

Popularity can also help with response. When widely used tools receive close attention, researchers and maintainers may find and patch flaws quickly. But that doesn’t remove the work of locating every affected instance, applying fixes and checking whether a particular weakness creates a viable route into a specific environment.

The response burden varies by maintainer. Large vendors can draw on established teams and information-sharing arrangements. Talos, for example, describes working with major vendors through Microsoft’s Active Protections Program, or MAPP. Vendors can share detection guidance or proof-of-concept details for flaws judged especially likely to see exploitation. Yves Younan, Talos’s director of vulnerability discovery, detection and testing, says Microsoft considers detection content based on its guidance important.

Talos says it has added resources to keep coverage ready as notifications arrive more frequently, sometimes on staggered or out-of-band schedules. Open-source projects face a different strain: some can distribute patch work among trusted contributors, while others rely on a wider community. The source warns that these projects underpin much of the internet, making maintainers’ capacity a practical concern.

Disclosure timing is under pressure

Coordinated disclosure gives a vendor time to prepare a fix before details become public. The customary window described in the source is about 90 days. That approach has supported patch development and helped defenders prepare, but some researchers now publish advisories without waiting for a window to expire.

The reasoning is that if one AI system can find a weakness, another may be able to find it too. That argument puts pressure on the assumption that keeping details private will buy a meaningful amount of time. Still, faster discovery doesn’t make the coordination problem disappear: maintainers need time to understand a flaw, create a fix and help users apply it. Expectations around timing are changing, and the source says guidance remains in flux.

Why the surge might ease

Past vulnerability trends suggest that discovery can spike when researchers focus on a newly recognized bug class, then taper as the available cases are examined. Format string vulnerabilities, identified as a class in 2000, rose to a peak in 2005 before declining over the following years. They still appear, but now make up a smaller share of yearly CVEs.

AI-assisted analysis could follow a similar pattern if much of the current work is clearing a backlog of older code. Once those weaknesses are found and fixed, teams could also run newer code through AI evaluation during development. That would move more bug checking earlier in the process, when a fix may be easier to make than after software has spread across production environments.

That outlook depends on assumptions, though. The source says AI has improved the search for known flaw types, rather than establishing a new vulnerability class. And even if the backlog shrinks, new code will keep arriving. There’s no guarantee that discovery volumes will fall on a predictable schedule.

Disclosure can also help attackers. They may examine a patch to infer where a flaw was and then look for unpatched systems. Human attackers have historically faced delays in analyzing fixes; AI may reduce that bottleneck. At the same time, exploitation often requires multiple weaknesses to be chained together, and the source says broader mitigation adoption has made such attacks harder.

Count exploitable risk, not advisories

The gap between advisories and observed exploitation is large in the figures presented. Of Microsoft’s 975 September advisories, three had in-the-wild exploitation detected. The source also reports that published CVEs rose 105% year over year, while additions to the Known Exploited Vulnerabilities list rose 37% over the same period.

Those measures don’t track the same thing. A KEV count reflects distinct vulnerabilities known to be exploited, not the number of attacks or organizations affected. Attackers can reuse a useful weakness against many targets, and a flaw can appear in an advisory without offering a practical attack path. AI can process code, reports and exposed surfaces quickly, but the source says it still can’t reliably judge how valuable a weakness is to an attacker.

For defenders, the operational question remains whether a flaw creates a route into their own systems. That calls for prioritizing exploitability and local exposure, rather than treating every advisory as equally urgent.

What teams can do now

Development teams can add current AI evaluation models to their build and review workflows, the source recommends. Running new code through these checks may be less demanding than applying the same scrutiny to decades of accumulated software, so teams can work through older code in manageable sections.

Operations teams still need to patch promptly, but patching alone won’t cover the time between disclosure and deployment. The source recommends interim protections, including LiveProtect for Cisco customers, alongside custom IPS or Snort rules that block traffic associated with unpatched flaws. It also calls for behavioral detection that can flag unusual traffic aimed at automation platforms.

The practical takeaway is to combine those measures with environment-specific prioritization and defense in depth. A rising advisory count signals more triage and maintenance work, but the slower growth in known exploited flaws offers a reason to focus that work on credible attack paths. The next test will be whether AI checks become routine in development and whether maintainers can keep response times workable as the backlog is examined.

Further reading: “Don’t swing at everything” and “Threat Source Newsletter: Discovery ≠ Exploitation”.