A security team can find more vulnerabilities and still fall behind. Every additional finding needs an owner, a decision, and a fix that survives contact with production. AI makes the discovery side faster. The repair queue still has to move.
In a report dated October 1, 2026, Google Threat Intelligence Group (GTIG) examines vulnerability discovery and exploitation in the AI era. It finds rising disclosure volumes, more observed exploitation, and a concentration of code-execution flaws among vulnerabilities identified as likely discovered with AI.
For developers and security teams, the useful question is what those findings change about tomorrow’s patch queue. Prioritize an affected system using its actual exposure, evidence of exploitation, and the access an attacker could gain. The number of alerts alone cannot make that decision.
What Google’s vulnerability data shows
The report examines disclosures from January 2025 through August 2026. Monthly disclosures rose from 5,045 in January 2026 to 10,740 in August. GTIG also reports that the average number of vulnerabilities observed being exploited increased from about 10.5 per month in 2025 to 18 per month during January through August 2026.
Those figures describe the wider vulnerability landscape. They do not mean AI found every new vulnerability, or that every disclosed flaw was exploited. GTIG explicitly warns that disclosure practices and concentrated vendor release cycles affect the totals. Its risk ratings are also its own threat-risk assessments, not CVSS severity scores.
The AI-specific comparison needs a separate qualification. Of the vulnerabilities GTIG could identify as likely discovered by AI, 50% led to remote code execution, compared with 26% across the broader CVE ecosystem. Remote code execution means an attacker can cause code to run on a remote system; the privileges and consequences depend on the affected component.
That is a consequential finding, but it is not a controlled comparison of an AI reviewer against a human. The report notes that researchers deliberately direct agents toward critical infrastructure and sensitive privilege boundaries. Public records also lack consistent AI-attribution metadata, and some cloud fixes never receive a CVE. Treat the percentages as evidence about the observed sample, not a universal success rate for AI security tools.
A published patch can start another race
A zero-day is exploited before a fix is available. An n-day is a vulnerability that is already publicly known. Defenders need to handle both, but the second category is easy to underestimate once a vendor announces a patch.
GTIG suggests that much of the recent growth in exploitation is concentrated in the weaponization of n-days. It also raises the possibility that attackers use AI to analyze patches, advisories, and differences between product versions. That is an assessment of the trend, not proof that every observed attack used AI.
One example in the report gives the timing a practical meaning. GTIG says it observed exploitation of CVE-2026-1731, a BeyondTrust vulnerability attributed to discovery by Hacktron AI, within four days of public disclosure. An AI-assisted discovery does not make the later exploitation AI-assisted by definition. It does show why the publication of a defensive finding can quickly become an operational deadline.
A patch being available therefore answers only the vendor’s part of the problem. Your team still needs to establish whether the vulnerable version is deployed, whether the relevant feature is reachable, and whether the update actually reached every affected instance.
The AI stack needs ordinary software security too
The same report tracks more than 1,500 AI-related vulnerability disclosures from January through August 2026. Its categories include agent orchestration, AI web applications, inference infrastructure, and experiment-tracking systems.
This expands the review beyond what a model says. A workflow editor may execute code. An inference gateway may hold provider credentials. A document-upload service may write files or fetch remote content. These are familiar application-security boundaries, even when the interface looks like a conversation.
The totals do not show that every deployment of these tools is vulnerable. They do make a useful inventory question unavoidable: which components actually sit between a visitor’s input and your tools, data, or credentials?
Keep the deployed version, exposure, owner, and update path for those components alongside the rest of your software inventory. Reviewing a system prompt will not establish whether an administrative endpoint requires authentication or a file upload stays within its intended directory.
Build the patch queue around exposure and evidence
Consider a hypothetical team with an affected, internet-facing AI gateway and a separate finding in an internal development tool. The gateway can reach production services and holds provider credentials. The development tool has a higher scanner score but is isolated from production. The team needs that context before deciding which fix goes first.
A workable triage record answers four questions:
- Are we affected? Confirm the deployed version, configuration, and vulnerable feature against the vendor advisory. A package name in a lockfile is a lead to investigate, not the whole answer.
- Can the vulnerable path be reached? Check internet exposure, authentication, internal access paths, and the privileges available to the component. An internal service can still matter if an attacker can reach it from another compromised workload.
- What evidence makes this urgent? Consult vendor notices, relevant incident intelligence, and CISA’s Known Exploited Vulnerabilities catalog. CISA describes the catalog as an input to prioritization. Absence from it is not evidence that a flaw is safe.
- How will we confirm the repair? Assign an owner, a target time based on risk, and a verification step. If a patch cannot be applied immediately, evaluate the vendor’s mitigations and record their limits and expiry.
For the gateway, verification might include checking the running version on every replica, repeating an authorized test in a controlled environment, and confirming that legitimate traffic still works. If there are signs of compromise, follow incident-response procedures as well. Installing a patch does not by itself remove an attacker’s existing access.
Use AI to shorten the work, with review still attached
AI can help compare an advisory with an inventory, trace an affected code path, or propose a regression test. It can also misread the deployed configuration or suggest a fix that changes an access rule. Keep the supporting evidence next to its recommendation.
Mandiant’s guidance on AI-assisted vulnerability management recommends isolated workloads, limited machine identities, and human oversight. In a development workflow, that can mean a narrowly scoped branch, synthetic test data, and a patch reviewed before it reaches production.
Linmas fits the review part of that workflow. Use a bounded security review to connect a proposed change to the risk it addresses, then verify the behavior through the application’s real access path. Linmas does not replace asset inventory, vulnerability intelligence, or patch deployment.
Start with one exposed AI service this week. Identify its owner and running version, check relevant advisories, and record how you would verify an update. A small repair queue with clear evidence is more useful than a larger list nobody can confidently act on.
Reporting is based on the linked GTIG report and supporting guidance, checked on October 3, 2026. The prioritization example and cover illustration are Linmas editorial material; they are not a Google benchmark or architecture diagram.