Google’s AI Study Supports Exposure-Based Patching
Google Threat Intelligence Group's 30 September study counts 2,076 vulnerability disclosures involving AI systems from January 2025 through August 2026. The researchers say only a handful were confirmed exploited in the wild and that they had not observed zero-day exploitation of AI infrastructure. Those are findings within Google's visibility, not a guarantee that other deployments are safe.
The practical question for a security team is narrower than the headline count: which of those flaws can an attacker reach in the services the organisation actually runs?
Find the reachable entry points
Start with each production AI service and draw the path from an external user to the model. Record the public host, application version, authentication boundary, gateway, agent tools and secrets available at each step. Include staging systems that still have production credentials or network access. BlackTree's LightLLM helper-port report shows why the model API is not the whole exposure map. Then compare installed versions and enabled features with the vendor's advisory, rather than treating a product name match as proof of exposure.
Prioritise an unauthenticated or internet-facing route to code execution, file access or key theft. Check whether a vulnerable endpoint is actually enabled and whether a gateway or network policy blocks it. A compensating control can buy time, but it should have an owner and an expiry date. Re-test the route after a patch or configuration change so that a closed ticket corresponds to a changed running service.
Keep the exploitation signal in context
The useful response is to separate confirmed exploitation, public exploit material, technical reachability and business impact in the queue.
A gateway with broad permissions may have a larger consequence than a locally installed tool with no untrusted input. Set a short review interval for exposed components because a disclosed flaw can become easier to exploit after technical details or working code circulate. If logs cannot show who called a sensitive endpoint, add that visibility while reducing access.
Test the boundary after the fix
An AI-generated finding is still a hypothesis. Require a reproducible attack path, the affected version, and a test that distinguishes vulnerable from fixed behaviour. Keep a record of the agent's input and source revision so a reviewer can see which assumptions shaped the result. A plausible explanation without a working boundary test should stay in investigation, even when its severity label looks urgent.
For the next patch cycle, choose a small set of exposed AI services and record a baseline: installed version, reachable endpoints, credential scope and logging. After remediation, verify the version in the running process, repeat the access test and review logs for unexpected calls. The result is a defensible priority list tied to actual exposure, with evidence that the fix changed the system an attacker could reach.
