Patch tsunami: how to prioritize vulnerabilities when AI surfaces historical bugs

On May 2, 2026 the NCSC warned of an imminent “patch tsunami”: AI is surfacing old bugs at a rate that blue teams cannot absorb. The next day, CISA added CVE-2026-31431 to the KEV catalog, a Linux local privilege escalation that had been in the kernel for nine years and was found through AI-assisted scanning.

For an SMB with a Linux fleet, ML dependencies, or cloud infrastructure, the operational consequence is direct: relevant patches will increase, and exposure time per patch matters more than before.

Short answer

The goal is not to patch faster, it is to decide faster. An SMB needs triage that classifies each CVE in under four hours, an SLA by criticality aligned with operational reality, and a way to apply temporary mitigations when the patch is not immediate.

Why the dynamic is changing

Before 2026	What is changing
New bugs at a stable rate	Historical bugs surfacing in waves
Exposure time measured in weeks	Exposure time measured in hours after KEV
POCs published days after the CVE	Simple POCs published almost in parallel
Defense by volume	Defense by prioritization

When a working POC appears within hours, “wait for the monthly cycle” is no longer viable for critical vulnerabilities with active exploitation.

Triage model

flowchart TD
  A[New relevant CVE] --> B{Is it in KEV?}
  B -- Yes --> C{Active in production?}
  B -- No --> D{Critical CVSS >= 8?}
  C -- Yes --> E[Urgent patch or mitigation]
  C -- No --> F[Schedule patch in cycle]
  D -- Yes --> G[Review in 24h]
  D -- No --> H[Standard queue]
  E --> I[Communication and evidence]
  G --> I

This flow does not replace a formal program. It enables anyone technical on the team to make the first decision without freezing.

SLA by criticality

Category	Criterion	Target time
KEV critical in production	Bug in KEV with the system in use	< 24 hours for patch or mitigation
High without KEV	CVSS >= 8 without confirmed public exploitation	< 7 days
Medium	CVSS 5-7.9	Monthly cycle
Low	CVSS < 5 with no risk context	Quarterly cycle
Informational	Hardening, not a concrete vulnerability	Technical backlog

These windows adjust to each company’s size and criticality. What matters is that they exist and are measured.

CVE-2026-31431 as an exercise

Question	Operational answer
Affected systems?	Servers, dev workstations, and CI with vulnerable Linux kernel
Public POC?	Described as a few-line POC
Is it in KEV?	Yes, added on May 3, 2026
Patch to apply?	Kernel version patched by the distribution
Temporary mitigation?	Restrict local users, add extra monitoring
How to verify?	Updated inventory and post-patch version check

Applying this checklist to each critical CVE makes response repeatable and auditable.

Mitigations when the patch is not immediate

1. Reduce surface: close users or services that are not needed.
2. Increase telemetry on affected hosts with specific rules.
3. Restrict lateral movement with temporary segmentation.
4. Limit sudo privileges and review membership in sensitive groups.
5. Document the mitigation with a review deadline.
6. Communicate the change and dependencies to the affected team.

Temporary mitigations last days, not months. Without a review date they become permanent technical debt.

Common mistakes

1. Treating every CVE the same and burning out the team.
2. Ignoring the KEV catalog and steering only by CVSS.
3. Waiting for the monthly cycle when a public POC appears in hours.
4. Applying a temporary mitigation and forgetting to log it.
5. Lacking an updated inventory of versions per host.
6. Communicating patches via ad hoc channels with no traceability.

Progress indicators

Indicator	Good	Bad
Triage time	< 4 hours for critical	”When someone gets to it”
Inventory coverage	> 95% of hosts with known version	Hosts with no owner
Time to KEV patch	Within the agreed SLA	Not measured
Open mitigations	With review date	Open-ended
Internal communication	Dedicated, logged channel	Improvised

Scaling the program

A small SMB can sustain this model with two to four weekly hours from the IT owner. Above a certain volume, three clear levers appear: automate the inventory, subscribe to private IOC feeds, and delegate triage to a rotating on-call. Real need depends on fleet size and sector.

Final criterion

When the rate of bugs increases, what separates a secure operation from a saturated one is not how fast patches are applied. It is the quality of judgment to decide what to patch now, what to mitigate, and what can wait. The “patch tsunami” is manageable when the team prioritizes with data and communicates with discipline.

Working sources

• NCSC advisory on the increase of bugs found with AI assistance.
• CISA Known Exploited Vulnerabilities (KEV) catalog as a priority reference.
• Linux distribution security advisories for kernel patch management.
• Technical decisions must be adapted to each company’s stack, criticality, and resources.