AI is finding more vulnerabilities - why updating matters more than ever

October 14, 2026

AI tools are finding vulnerabilities faster than ever, and attackers are exploiting them faster too. What the numbers show, and what it means for keeping Linux machines updated.

More vulnerabilities than ever

The number of published vulnerabilities has grown for years, and it's now growing faster. 2025 set a record with 48,185 CVEs, 20.6% more than the year before. In 2026, the pace picked up again: according to Google Threat Intelligence Group, the number of vulnerabilities disclosed per month doubled between January and July, from 5,045 to 10,477, and reached 10,740 in August.

A large part of the explanation is AI. In Canonical's words, language models and specialized AI agents have turned bug discovery from a manual, time-consuming process into a highly automated one. And the bugs AI finds tend to be serious ones: Google found that half of the vulnerabilities it could attribute to AI discovery allow remote code execution, compared to about a quarter of vulnerabilities overall.

Not only AI - also more counting

Some of the growth comes from how vulnerabilities are counted. The Linux kernel project now assigns CVE identifiers to its own bugs, and takes the view that almost any bug affecting a running system could be a vulnerability. Google counted around 5,000 kernel CVEs between January and August 2026 alone - with no observed zero-day exploitation among them.

The systems built to catalog vulnerabilities are struggling to keep up. In April 2026, NIST announced that CVE submissions had grown 263% between 2020 and 2025, and that its National Vulnerability Database would no longer add details to every CVE, only to the ones it prioritizes.

Most vulnerabilities are never exploited

A flood of CVEs doesn't mean a flood of attacks. Google found that only 0.23% of the vulnerabilities disclosed in 2026 - about one in 431 - were ever seen exploited in the wild. Most are minor, hard to reach, or in software that isn't widely exposed.

That's an important point, because it means treating every update as equally urgent doesn't scale. The useful question isn't "how many updates are pending?" but "which machines have a fix pending for something that matters?"

But the ones that are exploited, are exploited faster

For the vulnerabilities attackers do care about, the time between disclosure and attack is shrinking. One example from Google's report: a remote code execution flaw in BeyondTrust's remote support software, found with an AI tool, was exploited by one group within four days of being disclosed, and by five more within a week.

The broader trend points the same way. Rapid7 found that the median time from a vulnerability's publication to its listing in CISA's catalog of actively exploited vulnerabilities fell from 8.5 to 5 days, according to its 2026 threat report. Google also suggests that attackers may be using AI to compare patched and unpatched versions of software, turning the fix itself into a blueprint for an attack.

Put together: once a security fix is published, the information about what it fixes is public too, and the time it takes to turn that into a working attack is getting shorter.

Distributions are speeding up

Linux distributions are responding. In September 2026, Canonical changed how it ships kernel updates for Ubuntu: instead of a four-week regular cycle and a separate two-week cycle for security fixes, there's now one two-week cycle, with a new release every week. For serious vulnerabilities, Canonical also aims to publish safe workarounds within 24 to 48 hours of disclosure, to protect systems until the fix is out.

So fixes are arriving faster. But a fix in the repository doesn't protect a machine until it's installed - and that step is still up to you.

What it means for your machines

• Install security updates promptly. Automatic security updates are worth turning on for most machines - see Choosing when to update.
• Restart what you've updated. More frequent kernel updates mean more frequent reboots, and services keep running old code until they're restarted. The services-restart.sh plugin shows which ones are waiting.
• Prioritize what's exposed. A critical fix on an internet-facing machine comes first; a low-severity fix on an internal one can wait for the regular update. See What a critical update means.
• Stay on a supported release. Faster fixes only help releases that still get them. A release past its end of life gets none at all.
• Know where you stand. With twice as many vulnerabilities published each month, a list of pending updates is easy to ignore. What you need to see is which machines have security fixes waiting, and which of those are critical.

That last point is what OS Checker is built for: it separates vulnerable packages from merely outdated ones on every machine, and sends an alert when a machine gets a new critical issue.