Artificial intelligence is giving security researchers new ways to examine code, trace unusual behaviour and identify flaws that conventional tools may overlook. The pressure is particularly visible around Zero-day vulnerabilities, a recent Minimus analysis considers how container composition, dependency records and rebuild speed affect the response after an unknown flaw is exposed. Faster analysis helps only when organisations can also establish where the vulnerable software is running.
In May 2026, Google Threat Intelligence Group reported the first case in which it believed a threat actor had 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.
Researchers said they had high confidence that an AI model assisted with both discovery and weaponization. Their assessment drew on the script’s unusually detailed instructional comments, a fabricated vulnerability score and a highly structured coding style associated with generated output. Google did not claim that the wider operation was autonomous or attribute the code to a particular model.
The flaw itself is what makes the case significant. It involved a hard-coded trust assumption rather than a crash, memory error, or unsafe input. Fuzzers and static-analysis tools are well suited to finding many conventional implementation problems. A language model can also examine how permissions, functions and expected behavior interact across a codebase. That creates another route to finding logical contradictions that leave no obvious technical trace.
Google’s wider data suggests this was not an isolated concern. According to Google Threat Intelligence Group’s 2025 analysis, researchers tracked 90 zero-days exploited in the wild during 2025, compared with 78 in 2024. Enterprise software and appliances accounted for 43 cases, or 48% of the total. Both figures were records in Google’s dataset.
Complex containers make exposure harder to trace
Once a flaw becomes public, security teams first have to work out where it is running. That can be difficult inside a container environment. An image may contain operating-system packages, application libraries and dependencies inherited from its base image, alongside shells or utilities with little connection to the workload’s visible purpose.
A vulnerable component can therefore sit several layers below the application itself. It may appear across numerous images even when the organisation never added it directly.
Log4Shell exposed this problem at scale in 2021. The affected Log4j library had been incorporated into a wide range of products and services. For many organisations, obtaining the patch was only the beginning. They still had to identify every server, application and container carrying a vulnerable version before they could complete remediation.
Software bills of materials provide a clearer record of what each image contains. Smaller images can also reduce the search by excluding packages that the workload does not need. Minimus examines the issue through package reduction, dependency visibility and the rebuilding of images after an affected component is disclosed.
The benefit is simpler than preventing zero-days altogether. A minimal image can still contain an unknown flaw. It gives teams fewer packages to investigate, fewer possible exposure points and less software to replace or retest once the problem becomes known.
AI-generated fixes still need software 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. None of that is especially useful when package records are outdated or nobody knows which images contain the vulnerable component.
Earlier coverage of an AI agent designed to automate vulnerability fixes detailed how Google DeepMind’s CodeMender contributed 72 security fixes to established open-source projects during its first six months. The system combines model reasoning with static analysis, runtime testing and fuzzing to produce and assess proposed patches.
Those patches were not accepted automatically. Human researchers reviewed each change before it was submitted, checking for regressions and confirming that it addressed the underlying cause rather than only the visible symptom.
Even an approved code change does not finish the job. Teams must identify the affected images, rebuild them with the corrected dependency and test the result before deployment. In a poorly documented environment, locating every instance may take longer than producing the patch itself.
Accurate inventories give automated tools something concrete to work with. They connect a newly disclosed flaw to the package version, image and workload that actually require attention.
Finding the flaw may no longer be the slowest step
AI is speeding up code analysis for both attackers and defenders, but many delays still occur after a vulnerability has been identified. One team may spend hours opening images and checking package lists by hand. Another can search a current inventory and see almost immediately which workloads contain the affected version.
That difference has little to do with the sophistication of the discovery tool. It comes from decisions made earlier about software inventories, image composition and how containers are built and replaced. As vulnerability research moves faster, the practical advantage belongs to organisations that can establish exposure and deploy a tested repair without first trying to reconstruct what their systems contain.