Date: 11/3/2026

AI finds the flaws now, and your patch window was calibrated on a world that no longer exists

The slop has been over since spring; the volume has not. Half of the vulnerabilities attributed to AI discovery lead to remote code execution, against 26 percent of the rest, and for one flaw an AI agent found, Google saw exploitation within four days. What that changes in your patch process, and why one in 431 is the figure that puts the rest in proportion.

TL;DR

October was awareness month. In that same month something else shifted: AI now finds the vulnerabilities, and no longer as noise. That problem has been over since spring. What replaced it is harder, far more reports, at higher quality. Half of the flaws Google attributes to AI discovery lead to remote code execution, against 26 percent of the rest. And for one flaw an AI agent found by itself, Google saw the first exploitation within four days of disclosure. This piece is not about AI. It is about your patch window, which was calibrated on a world where a human had to find the flaw first.

Two critical flaws in one day was not bad luck

Last week I wrote about 21 October: two critical vulnerabilities in PHP and, on the same day, one in Node.js, and the crisis exercise that came out of it unasked. I called it a week nobody had scheduled. That was the generous reading. This year's figures say something else: that week was not an outlier but the new baseline, and one extra exercise a year will not cover it.

While the awareness campaigns were running, something changed in the pipeline that vulnerabilities come out of. It is less visible than a phishing mail in a newsletter, and it hits your planning harder.

The noise is over. The volume is not.

What almost everyone still has in mind is January. The curl project ended its bug bounty, and curl is one of the most widely used pieces of software in the world, almost certainly including your environment. Daniel Stenberg, its maintainer, wrote that the share of reports turning out to be real vulnerabilities fell below five percent in 2025: "Not even one in twenty was real." Dropping the reward was "an attempt to remove the incentives for submitting made up lies".

That picture is out of date. In April he wrote that it was over: "The slop situation is not a problem anymore." The confirmed-vulnerability rate was back at fifteen to sixteen percent, the pre-AI level, at roughly double the number of reports. And on 22 October, last week: "Since spring 2026 the slop reports are practically gone. Our current challenge is much harder: high volume, high quality." Of the reports from recent months, he wrote that every single one had AI involved to some extent.

This has not stayed theoretical. On 14 October curl received a HIGH severity vulnerability, CVE-2026-92392, a use-after-free in HTTP/2 uploads that can lead to code execution. Found by a scanner from Anthropic. The previous HIGH in curl dated from October 2023. The same day Stenberg published the result of an audit by Aisle, which he writes has by now produced thirty-five published curl CVEs, more than any group or individual ever did before.

So whether AI produces usable findings is no longer the interesting question. The interesting question is what several times the discovery capacity does to everyone who uses that software. That is you.

Two figures that touch your planning

Fifty against twenty-six

On 30 September, Google Threat Intelligence Group published an analysis of vulnerabilities in the AI era. One figure from it: "Exactly 50% of all AI-discovered vulnerabilities result in Remote Code Execution (RCE), compared to just 26% across the broader CVE ecosystem."

Remote code execution is the kind of flaw an attacker can actually do something with. That half of the AI-found flaws fall in that category and a quarter of the rest means the composition of what reaches you has shifted. Your agreement that critical findings are patched within thirty days was made on a mix in which most findings did not hand anyone a shell.

Google adds two caveats itself, and they belong here. These are vulnerabilities it could call "likely AI discovered", attribution is done by hand, because a CVE has no field for it. And the post calls the difference "an early indicator rather than an established trend", noting that part of the explanation is probably how research programs scope and aim their systems. So read it as a direction, not as a number for your risk register.

Four days

The second figure is more concrete. CVE-2026-1731 was a vulnerability in BeyondTrust Privileged Remote Access and Remote Support that let an attacker run commands without logging in. According to Google it was found by a third-party research agent working on its own, Hacktron AI.

What happened next is the point: "within four days of public disclosure, GTIG observed a threat cluster exploiting this vulnerability, followed by five additional threat clusters within seven days of public disclosure." Four days to the first, a week until six groups were on it.

Hold that against your own agreements. At that pace a thirty-day window for critical findings is not a window but a gap. And it is not only pace: by the same analysis, monthly published vulnerabilities went from 5,045 in January 2026 to 10,740 in August.

And now the figure that puts the rest in proportion

Of all vulnerabilities disclosed in 2026, Google observed 0.23 percent actually being exploited. Roughly one in 431. Anyone who has read this far and now wants to work through their entire list is doing exactly the wrong thing.

Google warns itself that the counts are inflated. Automated CVE assignment in open source does a lot of the work: vulnerabilities with "Linux Kernel" in the description alone generated some 5,000 CVEs between January and August, without a single exploited zero-day among them.

So the risk is not in the count. It is in the gap between that stream and an inventory you cannot query within the hour. That is the same conclusion as 21 October, when the question "do we run this, and in which version" was the obstacle for many organizations rather than the patching. Which finding you leave alone is a decision with an owner, not a backlog.

So which of those 431?

That is the question left over, and two public lists answer a large part of it. CISA maintains the KEV: vulnerabilities confirmed to be exploited in the wild. If something is on it, it is no longer an estimate. EPSS from FIRST works the other way round and gives each CVE a probability of being exploited within thirty days, recalculated daily and freely available as CSV or through an API.

Both have a shortcoming you need to know before you steer on them. KEV lags by definition: it tells you what has already happened, and at four days to first exploitation you cannot wait for it. EPSS is a probability and not a verdict, a low score on something that is internet-facing and gives code execution is no reason to leave it alone.

And neither knows whether you run it. That is why they do not replace the previous paragraph but add to it: together they turn ten thousand findings into a few dozen, and after that you still have to be able to say within the hour whether one of them runs at your place. Shortening the list does not help you while that question is open.

Your own AI layer is now in the queue too

A part of the same analysis that is easily missed: AI does not only find vulnerabilities, plenty are coming out in AI software itself. Google counted 2,076 AI-related CVEs between January 2025 and August 2026, over 1,500 of them in 2026 alone. The middleware that wires agents together is the largest group in that, half of all AI-related flaws, with a 347 percent rise this year. The post names visual workflow builders such as Flowise and Langflow explicitly.

If someone in your organization has put an agent into a process, that middleware now sits in the same row as your web servers: software with a version number, exposed to the internet, holding permissions in your environment. That is not an AI question but ordinary operations, and it is exactly the kind of dependency you do not control yourself.

One nuance from Google on top, because it points the other way: it has not yet seen zero-day exploitation of AI infrastructure. What it does see is that freshly disclosed flaws in exposed middleware get picked up quickly.

Five things you change because of this

Hang your threshold on exposure, not on a score. Internet-facing and code execution: hours, not days. The rest by exposure. Four days to first exploitation leaves no room for a monthly cycle. Count on there being no patch yet in those hours; then the question is not how fast you patch but what you shut, the service, the feature, or the access to it.
Make sure you know within an hour what you run, and in which version. Not an annual inventory, but a list someone can query at eleven at night. That was the obstacle on 21 October, not the patch. Do not start with everything: start with what is reachable from outside, because that is a short list and it is the list that counts.
Separate the decision from the patch. Record who may take a service offline and at what threshold, with a name and a deputy behind it, and whether that also holds for the second decision the same day. That is exactly the authority you need on the day there is no patch yet.
Put your AI middleware in the same process as your web servers. Flowise, Langflow, an agent of your own: track the version, know the exposure, bound the permissions.
Do not measure the number of CVEs. One in 431 gets exploited, so a rising counter says little. Measure for how many of your internet-facing services you know the version. That number should be a hundred percent and almost never is.

Where I think this is going

This is my expectation, not a figure. On 20 October Stenberg announced that from 26 October curl wants reports of LOW and MEDIUM severity out in the open, as ordinary GitHub issues; only HIGH and CRITICAL stay private. That is what it looks like when triage capacity runs out and someone is honest about it.

If more maintainers do the same, lighter findings become public sooner. For an attacker that is material, and for you it means the period between "it is known" and "it is being used" shrinks further. Not for the critical ones, those stay private, but for the large middle band you currently allow a month for.

Frequently asked questions

How do I get that inventory within an hour?

Not with a six-month project, because then it arrives exactly in time for the next wave. Start with what is reachable from outside: which of your names and addresses are on the internet, what software runs behind them, and in which version. In most organizations that is a few dozen lines, not thousands. Put one owner on it and a date on which it was correct. A list that is eighty percent right and that you can open tonight is worth more than a complete inventory six months from now.

Should we buy an AI scanner now?

Probably not first. These figures are about finding flaws in software you use, not software you write. If you do develop, such a scanner in the pipeline is worth considering, Stenberg writes that curl's reviews would be worse without them. But in most organizations the brake is on the inventory and on the authority, not on the finding. Buy in that order.

Does this apply if we do nothing with AI?

Yes, and that is the core of it. The change is upstream, with whoever finds the flaws in the software you run. Whether you use AI makes no difference to that; it only decides whether item four on the list above applies to you as well.

Is that fifty percent not just a measurement artifact?

Partly possible, and Google says so itself: an early indicator, in which the way research programs aim their systems plays a part. Use it as a direction. The figure your planning may actually turn on is the four days, because that is observed exploitation and not attribution.