Artificial intelligence is changing vulnerability response in a more uneven way than a simple race between attackers and defenders. It can help researchers spot flaws, help teams draft fixes and help both sides work through code faster. But once a vulnerability is disclosed, the hardest step is often still the same: figuring out exactly where the affected software is running.
AI is widening the search for flaws
Security researchers are using AI to inspect code, follow unusual behavior and look for problems that conventional tools may miss. That matters most for zero-day vulnerabilities — flaws that are unknown to vendors or defenders before they are exploited.
In May 2026, Google Threat Intelligence Group reported the first case in which it believed a threat actor used AI to help develop a zero-day exploit. The exploit appeared in a Python script and bypassed two-factor authentication on a widely used open-source system administration tool when valid credentials were already available. Google said it had high confidence that an AI model helped with both discovery and weaponization, but it did not claim the operation was autonomous or identify a specific model.
The case is notable because the flaw was not a classic crash or memory-safety bug. Instead, it involved a trust assumption in the software’s logic. Traditional tools such as fuzzers — programs that feed unusual inputs into software to trigger failures — and static analysis tools are good at finding many implementation errors. A language model can also reason across permissions, functions and expected behavior, which gives it another path to exposing contradictions in how software is designed.
Google’s broader data suggests the pressure is not limited to one case. In its 2025 review, the company said researchers tracked 90 zero-days exploited in the wild during 2025, up from 78 in 2024. Enterprise software and appliances accounted for 43 of those cases, or 48% of the total.
The real delay often starts after disclosure
Finding a flaw is only part of the response. Security teams then have to determine where the vulnerable component exists across servers, applications and container images.
That step can be difficult in container environments because an image may include operating-system packages, application libraries and inherited dependencies that are not obvious from the application itself. A vulnerable package can sit several layers below the workload and appear in many images, even if the organization never added it directly.
The Log4Shell incident in 2021 showed how much work that creates. The affected Log4j library was embedded in a wide range of products and services. For many organizations, patching the library was only the beginning; they still had to identify every affected system before remediation was complete.
Software bills of materials, or SBOMs, help by listing what is inside a software image or package set. Smaller images can also reduce the problem by excluding components a workload does not need. The point is not that a minimal image prevents unknown flaws. It is that it leaves fewer packages to inspect, fewer possible exposure points and less software to rebuild or retest when a vulnerability is disclosed.
AI can help patching, but only with accurate context
AI is also being used to shorten the time between disclosure and patch development. Models can inspect source code, compare vulnerability reports with package records and propose changes for affected versions.
One example mentioned in recent coverage is Google DeepMind’s CodeMender, an AI agent that helped produce 72 security fixes for established open-source projects in its first six months. The system combines model reasoning with static analysis, runtime testing and fuzzing to generate and evaluate patches.
Those changes were still reviewed by humans before submission. That review mattered because a patch has to fix the underlying cause, not just the visible symptom, and it must not introduce a new regression.
Even after a patch is approved, the work is not finished. Teams still need to find every affected image, rebuild it with the corrected dependency and test it before deployment. In a poorly documented environment, locating all instances can take longer than creating the fix.
What determines whether AI actually speeds response
AI can compress parts of the vulnerability workflow, but it does not remove the need for software inventories and rebuild discipline. The organizations that respond fastest are usually the ones that already know which package version is where, which images include it and how quickly those images can be replaced.
That is the practical shift. As vulnerability research gets faster, the bottleneck moves toward exposure mapping and clean remediation. Teams that can connect a newly disclosed flaw to a current inventory are better positioned to act without first reconstructing what their systems contain.