AI Drives Vulnerability Discovery and Stalls the Pace of Patches

While the AI industry publicly debates a possible pact to slow down the development of frontier models, a much more concrete side effect is already underway: an explosion in the number of vulnerabilities discovered in software, fueled by widely available generative AI tools, including open-weight models. That's what a Wired report shows, gathering data from major software vendors to illustrate the size of the jump.

The numbers are at the core of the problem. Microsoft announced last week that it had issued patches for 974 CVEs in September alone, a record for the company. In July, Oracle released 1,448 fixes, compared to 309 in the same month of 2025, a jump of more than 4.5 times. The two main Chrome versions released in June brought a combined 1,072 fixes, more than the sum of all 23 previous major versions of the browser. And Mozilla reported, in April, having found 271 vulnerabilities in Firefox in a single bug-hunting sprint using Anthropic's Mythos model.

In aggregate, the cve.icu project, maintained by Jerry Gamblin (head of research at Empirical Security and founder of RogoLabs), had logged 66,401 CVEs as of the last Wednesday of September this year. On September 16, 2025, the cumulative total was 33,512, almost half of the current number. For historical comparison: in 2022, the year OpenAI launched the first version of ChatGPT, the total number of CVEs recorded for the entire year was 25,000.

What Changes for Those Keeping Code in Production

This isn't an abstract debate about the future of AI: it's an operational problem already knocking on the door of any team that maintains dependencies, does patch management, or operates CI/CD pipelines with security scanners attached. More CVEs discovered means more alerts arriving in tools like Dependabot, Snyk, or Trivy, more triage tickets, and more pressure on squads that already couldn't keep up with the previous volume. In Brazil, where much of the corporate infrastructure runs on Oracle databases, Chromium-based browsers, and an open source ecosystem (npm, PyPI, Maven) maintained by a handful of volunteers, the effect is direct: banks, fintechs, and public agencies that depend on these stacks will see the volume of security advisories grow at the same pace reported by Wired, without the headcount of AppSec teams growing along with it.

Jerry Gamblin, whose cve.icu tool is a reference for tracking these numbers, argues that the increase isn't necessarily a tragedy. "I don't think it's being exaggerated," he told Wired. "What I question is the idea that a bigger number is, in itself, the harm. More CVEs isn't more vulnerability. It's more known vulnerability, which most of the time is the system working." In other words: discovering more flaws before attackers find them is, in theory, a win for defenders. The problem is what comes after the discovery.

The Bottleneck Isn't Finding the Bug, It's Fixing It

The UK's National Cyber Security Centre sums up the central point cited in the report: "Simply finding vulnerabilities does nothing to improve your security." Discovery scales with computing power, available to any team (or attacker) that runs an open model against a codebase. Remediation, on the other hand, still depends on people: reviewing the finding, writing the patch, testing for regressions, coordinating the release, and, in the case of open source libraries, convincing a volunteer maintainer to merge the change. As Gamblin himself sums it up: "Discovery scales with compute. Remediation scales with people, and people are the part you can't just buy more of in a quarter."

This mismatch is especially cruel for open source. Projects maintained by one or two people in their spare time have already lived under security pressure for years (the XZ Utils case in 2024 is the industry's most cited example); now they're also receiving AI-generated vulnerability reports in greater volume, many of them legitimate, but not all correctly prioritized. For Brazilian squads that pull these libraries via npm install or pip install without a second thought, the practical lesson is to double down on SBOM (software bill of materials) and on CVE triage processes based on real criticality, not on the raw volume of alerts coming in.

Two Sides of the Same Tool

The report also brings the perspective of those monitoring threats from the offensive side. Matthew Olney, director of threat intelligence at Cisco Systems, notes that attackers are in the same trial-and-error process as defenders: "Malicious actors, just like the industry, are trying to figure out where to use AI." This means that, for now, there's a fragile balance: the same capabilities that allow Mozilla to find 271 bugs in Firefox in a sprint are also available to those who want to exploit flaws before they're fixed. There's no evidence today that one side is systematically ahead of the other, but the growing volume of CVEs makes the window between discovery and exploitation increasingly tight for those who don't automate their own response.

What Remains Open

The discussion about a coordinated pause in frontier model development, driven by fears of more dramatic existential risks, remains open among AI labs. But, as Wired points out, even if that pause happens, it doesn't reverse the wave of vulnerabilities already unleashed by AI tools available today, whether commercial products or open models running locally. For engineering and security teams, the practical takeaway doesn't depend on any regulatory decision: the volume of CVEs is here to stay, and the response needs to come from better patch prioritization, more investment in remediation automation, and less reliance on a human manually reviewing every alert, because that human, as Gamblin reminds us, doesn't scale at the same pace as compute.