How fast should you patch now that AI hunts for bugs?

On 4 November, OpenAI reported that a pipeline running an unreleased model produced 948 working Linux root exploits (opens in a new tab) in about 30 hours, at $1,279 each. In the Hacker News thread about it, one commenter (opens in a new tab) asked what plenty of us were thinking: "how is the internet still up?" So how fast should you patch now that AI hunts for bugs? The instinct is to patch everything, faster. The numbers say sort first: disclosures doubled this year, the share of bugs anyone exploits didn't rise, and the time you get once a bug matters shrank. A small team's job is to find the few updates that matter and move very fast on those.

TL;DR: Patch anything internet-facing and known to be exploited within three days, the deadline US federal agencies now work to. Run everything else through an automated update lane with a three-day cooldown, merged only when your tests pass. Disclosures doubled this year, and only 0.23% of them have been seen exploited.

Does AI bug hunting make every vulnerability urgent?

AI bug hunting is part of why disclosed vulnerabilities doubled this year, and the share attackers use stayed tiny. Google Threat Intelligence (opens in a new tab) counted 5,045 disclosures in January 2026 and 10,740 in August. Only 0.23% of this year's disclosures, about 1 in 431, have been seen exploited in the wild. VulnCheck (opens in a new tab), a vulnerability intelligence firm, counts more widely and gets 1.4% for the first half of 2026, down from 2.7% in late 2023. Both numbers lag, since exploitation can surface months after disclosure, but neither shows the share climbing with the volume.

AI-found bugs look like the rest. VulnCheck tracked 1,061 vulnerabilities attributed to AI-assisted discovery in the first half of 2026 and found 14 confirmed exploited, or 1.3%, about the rate of every other bug that period.

That's most of the answer to the Hacker News question. Finding a bug and using it against you are different jobs. Exploitation is still rising in absolute terms, from 10.5 vulnerabilities a month in 2025 to 18 in 2026 on Google's count, so you can't relax either. What you can do is stop treating your scanner's list as a to-do list, because a queue sorted by raw count sends you to the wrong tickets.

What got faster for attackers?

Turning a public bug into a working attack now takes less time. VulnCheck's median time from CVE publication to known exploitation fell from 120 days in 2025 to 80 in the first half of 2026. Google reads the 2026 growth as attackers quickly weaponizing bugs that are already public, and suggests LLMs may be helping them read patches and advisories.

CVE-2026-1731, in BeyondTrust's remote support products, was found by an AI research agent. Google saw a threat group exploiting it within four days of disclosure (opens in a new tab), and five more within seven. Four days is the number I'd plan around. Some bugs don't give you even that: VulnCheck found 23.43% of known exploited vulnerabilities were hit on or before the day their CVE was published.

A monthly patch day misses that window, and nobody can rush every disclosure, so the first job is sorting.

How fast should you patch a known exploited bug?

US federal agencies now get three days. Binding Operational Directive 26-04 (opens in a new tab) from CISA, the US cyber agency, issued in June 2026, replaced the old severity-first rules with four questions: is the asset publicly exposed, is the bug in the Known Exploited Vulnerabilities catalog, can an attacker automate every step, and does it give partial or total control of the system? CISA says plainly that attackers' use of AI "may further narrow the time defenders have to react."

A few rows from the timeline table (opens in a new tab):

The directive binds federal agencies, so nobody is coming for your startup. I still think it's the best free decision table around, because it ignores the severity score and asks whether the bug can reach you. CISA says it publishes three of the four answers for every CVE, through data like Vulnrichment (opens in a new tab). The catalog (opens in a new tab) had 1,768 entries on 4 November, which is a list one person can watch. The fourth answer, whether your thing is exposed, only you have.

What should a small team's patching policy say?

One page is enough: three lanes, each with a deadline and a name next to it. I've been building for the web since 2014, and this is the version I'd write today, cut down from CISA's table.

1. Three days: exposed and known exploited, or exposed, automatable and total control. Your web framework, reverse proxy, CMS, VPN, anything with a public login page. One named person watches the catalog's email alerts and your repo's security alerts, since the catalog only lists a bug once it's being exploited, then checks the lockfile and the servers and ships that day. CISA starts the clock when a bug is listed or when you find it on your system, whichever comes first, and I'd do the same. If it was in the catalog and gave total control, also look for signs someone got in before you patched.
2. Fourteen days: any other exposed bug, or internal and known exploited. Same person, normal release, no weekend.
3. Automated: everything else. A bot opens the pull request, your tests decide, and it merges. Upstream is shipping more fixes than anyone can read: Postgres developer Robert Haas counted (opens in a new tab) commits back-patched to Postgres's prior stable branch going from 248 in 2025 to 433 in 2026 over the same months, up 74%, because of bugs people found with LLMs.

Should you merge updates the day they ship?

Routine updates should wait a few days, and this is where "patch faster" runs into supply chain risk. On 30 October, the security firm Phorion reported (opens in a new tab) that versions 2.1.312 and 2.1.313 of the Claude Code extension on the Cursor Marketplace carried an SSH backdoor. Cursor pulled them. A dependency bot wouldn't have touched that extension, but packages carry the same risk: the newest release has had the least scrutiny.

Renovate and Dependabot both let routine updates wait. Renovate's security preset (opens in a new tab) waits until an npm package is three days old, to give malware researchers and scanners time. Dependabot's cooldown (opens in a new tab) defaults to 3 days and applies only to version updates, never security updates. GitHub's own CLI runs a cooldown in its dependabot.yml (opens in a new tab):

Checked daily, and new releases wait three days. OWASP's guidance (opens in a new tab) says a cooldown "must never delay a fix for an actively exploited vulnerability," and warns that a later Renovate rule can quietly re-apply the delay, so read your own config.

The one gotcha is automerge. Renovate's docs (opens in a new tab) warn that without a required status check, "GitHub might automerge PRs with failing tests!" Your tests catch a release that breaks your app, and they won't catch a malicious one, which is the job of the cooldown. If your tests are thin, keep a person on the merge button until they aren't.

Do OpenAI's 948 Linux exploits change anything for your servers?

OpenAI's 948 exploits matter most if strangers' code runs next to yours, like on shared hosts and CI runners. They're local privilege escalation, so an attacker needs an account on the machine first, and on a single-tenant box they only come into play after something else lets the attacker in. OpenAI's advice is still blunt: a low-privileged account on an out-of-date system "should be considered functionally equivalent to root access for a well-resourced threat actor."

That turns one bug in your web app into the whole server. So give the operating system its own automated lane, because a bot watching your lockfile never sees it. On Ubuntu that's unattended-upgrades for security updates. A new kernel package also doesn't protect a running machine until it reboots, so schedule the reboot too.

What if the patch hasn't reached you yet?

A fast policy still waits on your vendor, so the three-day lane needs a fallback. Ubuntu's page for CVE-2026-98432 (opens in a new tab), a Linux TCP flaw it rates Critical, was published on 15 October. On 5 November it still listed 22.04, 24.04 and 26.04 as vulnerable with fixes in progress, and offered a firewall mitigation in the meantime.

CISA counts this kind of move: taking a system off the internet is a valid mitigation, and it changes the deadline. So for each thing in your first lane, write down what you'd do with no patch available. Block the port, disable the feature, or move the workload.

What to do this week

List what's reachable from the internet; that's your first lane. Sign up for the catalog's email alerts and give them to one person. Turn on an update bot with a three-day cooldown, require passing checks before it can merge, and turn on your server's automatic security updates. Then write the three deadlines down, with a name next to each.

More posts on building software are on the gabs.app blog. I'm a full-stack engineer and my work is on gabs.app; if you're hiring, the contact form comes straight to me.