The 2026 flood of vulnerabilities: what AI has changed

For a long time, finding security flaws was the bottleneck. In 2026, AI models are taking over a growing share of that work, and they find flaws faster than teams can close them. Google's Threat Intelligence Group counted 5,045 published vulnerabilities in January 2026 and 10,740 in August. That is more than double in seven months.

For management, this has a concrete consequence. More advisories land with the same people who install the updates today. The question to settle is which flaws get closed first and who decides about the rest.

What AI has changed about finding flaws

In April, Anthropic presented Project Glasswing. According to the company, its Claude Mythos Preview model has found thousands of high-severity vulnerabilities, including some in every major operating system and web browser. One of them had been in OpenBSD for 27 years, an operating system known for its hardening. Anthropic does not plan to make the model generally available. We described in April why findings like these break the old security model of companies, in AI Finds Vulnerabilities: Resilience Is Now the First Obligation.

FIRST, the global forum of incident response and security teams, names AI as a key driver of the flood. At Mozilla, the number of CVEs, the publicly registered vulnerabilities, rose by 164 percent in the first quarter. FIRST attributes this directly to AI tools running against the code of the Firefox engine.

In June, FIRST raised its projection for the full year from 59,427 to around 66,000 vulnerabilities. By then, disclosures were 46.3 percent above the level FIRST had forecast in February for that period. According to FIRST, this puts annual disclosures on pace to approach 70,000 for the first time.

AI is not the only cause. FIRST also points to structural factors that inflate the figures. How many flaws were found with AI cannot be read from public data, because CVE records carry no uniform tag for it. Google notes this as well.

An example: the firewall with few reported flaws

OPNsense shows how this reaches day-to-day operations. It is an open-source firewall that sits between a company's network and the internet and controls which traffic may pass in and out. For years, few of its flaws were publicly registered. The US National Vulnerability Database (NVD) lists 23 entries for OPNsense across the eight years from 2018 to 2025. In seven of those years there were three at most; only 2023 had 15.

By 25 October 2026, another 30 had been added. Ten of them were added retroactively for a version from 2019. The project itself published 31 security advisories in its GitHub repository between March and the end of September, five of them rated critical. On 1 July, nine arrived on a single day.

Among those nine was a critical flaw that allowed code execution as root, meaning full control of the firewall. heise reports a CVSS score of 9.9. On this scale for the severity of a flaw, 10 is the maximum. Most advisories do not say whether AI helped find the flaw. One of the 31 explicitly mentions AI assistance in reading the code and writing the report.

In our view, the cause matters less for operations. Anyone running OPNsense had nine advisories to assess on 1 July, for the device where the company network meets the internet. Every further product in the building makes the list longer.

A small share is exploited, and the number is rising

The figure that should set the order is in Google's analysis. Only 0.23 percent of all vulnerabilities published in 2026 were ever observed in active exploitation, roughly one in 431. Entries concerning the Linux kernel alone produced about 5,000 CVEs between January and August. Google observed none of them exploited as a zero-day, that is, before an update was available.

Still, the absolute number is rising. Google counted 141 exploited vulnerabilities from January to August, more than the 127 for the whole of 2025. Since May, according to Google, exploitation has grown almost exactly as fast as the number of disclosures.

The number of vulnerabilities is therefore not a useful yardstick for the work inside a company. What counts is which ones are being exploited and whether they are in your own systems.

Patching is the bottleneck

FIRST puts it this way: when AI can find far more flaws than human analysts, discovery is no longer the constraint. What runs short is the human capacity to verify, coordinate and patch. FIRST advises organisations to plan for a doubled patching workload.

Whether today's IT staffing can carry twice the load is a question for management. In a company with a small IT team, treating every advisory the same way means falling behind. We explained in September why the bottleneck is moving from finding to fixing, in Why AI-run attacks usher in the golden age of cybersecurity.

What management should decide

In our view, four decisions put the growing workload in order. They apply in this sequence.

A current inventory of systems

An advisory matters only if the affected product runs in the affected version on your systems. Without a current inventory of systems and versions, that question has no answer, and every advisory turns into research of its own. Management should explicitly free up the time to build that inventory.

Exploited vulnerabilities first

The US agency CISA maintains the Known Exploited Vulnerabilities catalogue, in its own words the authoritative source of vulnerabilities that have been exploited in the wild. CISA recommends using it as an input to your own prioritisation. If a flaw in your estate is listed there, it comes first. For the rest, FIRST's Exploit Prediction Scoring System, or EPSS, estimates how likely a CVE is to be exploited in the next 30 days. The CVSS base score alone does not order the list. It describes the severity of a flaw by its fixed characteristics and says nothing about whether anyone is exploiting it.

Internet-facing systems before the rest

Firewalls and VPN gateways sit between your network and the internet. If the affected function can be reached from outside, a critical flaw there weighs more to us than the same score on a machine inside the network. An attacker can then reach it without a further step.

Who decides on a postponement

Not every vulnerability can be closed at once. Some updates need testing, others a maintenance window. When a fix is deliberately postponed, it should be clear who decided, until when and on what grounds. Management should set in advance from which severity it decides itself. Then you can show in an audit that the risk was carried knowingly.

Where AI helps the defence

In our view, the same technology that contributes to the flood can help to work through it. A model reads the advisory, matches it against the inventory of your systems and suggests whether it applies and how urgent it is. The decision on what gets closed first and which risk the company carries stays with people.

If you want to go further, have an AI attack your own software before a stranger does. How we do that every night against a copy of our platform is described in We get hacked every night.

Nothing in the figures suggests the workload will shrink this year. Know what you run and close the exploited ones first, and you have a list you can work through.

Sources: Google Threat Intelligence Group, 30 September 2026; FIRST, Mid-Year Vulnerability Forecast, 15 June 2026 and the accompanying blog post; Anthropic, Project Glasswing, 7 April 2026; OPNsense, security advisories on GitHub; NVD, keyword search “opnsense”; heise, 6 July 2026; CISA, Known Exploited Vulnerabilities Catalog; FIRST, EPSS; FIRST, CVSS 4.0; OPNsense, documentation. Accessed on 24 and 25 October 2026.