AI Is Making Vulnerabilities Easier to Find Than Fix

The bottleneck has moved downstream

For years, one limit in vulnerability management was discovery. Only so many skilled researchers could audit code, fuzz targets or manually review complex systems. AI-assisted workflows loosen that constraint. They let more researchers, vendors and attackers inspect more code paths, generate more test cases and produce more reports.

That is not inherently bad. More known vulnerabilities can mean less hidden risk. WIRED quoted RogoLabs founder Jerry Gamblin warning against treating the number itself as the harm, while emphasizing the imbalance that follows: discovery scales with compute, but remediation scales with people.¹

That distinction matters for enterprise planning. A CVE is an input, not an outcome. Before it becomes a closed risk item, a team must answer several questions: Is the affected component present? Is the vulnerable version deployed? Is it reachable? Are compensating controls in place? Is there active exploitation? Is a patch available? Will the patch break dependent services? Who owns the system? When can it be changed?

AI reduces some research and enrichment costs, but it does not eliminate those questions. In many organizations, it increases how often they must be asked.

Same-day CVEs show the triage burden

The September 19 CVE feed illustrates the work arriving continuously for defenders. A critical Gravity Forms vulnerability affecting versions up to and including 3.1.0.4 was published at 02:27 UTC, with a CVSS 3.1 score of 9.8. The record describes an unauthenticated arbitrary file upload path that could make remote code execution possible under specific form conditions.²

Minutes matter for internet-facing WordPress estates, but the response is not as simple as patching everything immediately. Teams must determine where Gravity Forms is installed, whether affected versions are present, whether public forms include hidden file upload fields and whether emergency controls can reduce exposure while upgrades are tested.

Another same-day WordPress plugin record, CVE-2026-92229 for Forminator Forms through version 1.57.2, was scored critical at 9.1. CISA ADP enrichment marked the issue automatable and assessed total technical impact.³ That combination should move the item up a risk queue, but only after asset exposure is confirmed. An enterprise that does not run the plugin should not spend the same effort as one with thousands of public-facing sites using it.

A third record, CVE-2026-87909, described a WP Photo Album Plus remote code execution path through ImageMagick argument injection and scored it high at 7.5. Unlike the unauthenticated examples, it required subscriber-level access or above and was marked not automatable by CISA ADP.⁴ That difference is why prioritization cannot rely on severity scores alone. Authentication requirements, exploit automation and business exposure all change the remediation order.

CVE-2026-89274, another critical WordPress plugin issue, affected WP Recipe Maker through version 10.8.1 and involved arbitrary shortcode execution through recipe comment content, with successful exploitation depending on the comment approval path.⁵ For a patch team, that means the decision tree must include not only software versioning but also site configuration, moderation workflow and whether vulnerable functionality is enabled.

Some cases demand a faster answer. CVE-2026-93741, a Totolink A3002MU buffer overflow, was scored critical at 10.0, and its CVE record states that the exploit had been released publicly and could be used for attacks.⁶ Public exploit availability changes the remediation calculus. Even if a device class is less visible in centralized software inventories, it may deserve immediate network controls, replacement planning or vendor escalation.

Together, these examples show the real load on security operations. The issue is not just the number of CVEs. It is the heterogeneity of each record: different products, exploitability, prerequisites, asset classes, owners and mitigations.

AI infrastructure adds another surface

The vulnerability surge is also arriving as enterprises add AI development infrastructure that must be secured and patched. IntelFusions reported on September 19 that Docker closed two flaws in Docker Sandboxes for AI agents and other untrusted code on macOS. One was rated 9.4 and could let code in the sandbox reach host files.⁷

That example is strategically important for platform teams. Sandboxes, agent runtimes, model gateways, vector databases, code-execution tools and developer copilots are becoming part of the production engineering stack. They are also new sources of advisories, emergency updates and architectural review. The systems introduced to manage AI risk can themselves become additional patch-management obligations.

The same dynamic compounds the broader security workload. TechManNews described the security function as squeezed by AI-assisted vulnerability discovery, quantum-readiness projects and supply-chain malware pressure arriving at the same time.⁸ Even when those pressures differ technically, they compete for the same engineering calendars.

What CISOs should measure now

CISOs should treat vulnerability volume as a capacity-planning signal, not only a threat-intelligence metric. Counting critical CVEs is less useful than measuring how quickly the organization can turn a relevant advisory into a validated disposition.

Useful measures include mean time to identify affected assets, percentage of CVEs automatically matched to an owner, percentage of internet-facing critical exposure resolved inside policy, number of exceptions older than 30 or 60 days, and the ratio of emergency patches to planned patch windows. These metrics show whether the organization is absorbing the discovery surge or simply moving risk into a backlog.

Teams should also separate intake automation from remediation automation. AI and rules-based enrichment can summarize CVEs, extract affected versions, map CPEs, compare SBOMs and draft tickets. But production change should still require clear ownership, rollback planning and evidence that the patch or mitigation worked. The goal is not blind autopatching across all systems. It is reducing manual toil before judgment is required.

What platform teams can do

Platform engineering teams are in the best position to shrink the human bottleneck. Standardized service catalogs, accurate dependency inventories, deployable SBOMs, golden base images and paved-road patch pipelines all make vulnerability response less bespoke.

The practical priority is to make the common path fast. If most services use standard images, managed runtimes and automated test suites, many fixes can move through predictable pipelines. If every application is an exception, every CVE becomes a consulting project.

Risk-based patching should also be explicit. A newly disclosed, public-exploit, network-reachable vulnerability should not wait behind a high-scoring issue in an internal-only component with no practical exposure. Conversely, teams should avoid burning scarce response capacity on irrelevant CVEs simply because they are labeled critical.

The near-term risk is operational imbalance

AI-assisted vulnerability discovery may improve security over time by exposing flaws earlier and giving defenders more information. But in the near term, it creates a throughput problem. Discovery is accelerating faster than most organizations can validate and fix.

That makes vulnerability management an engineering capacity issue as much as a security issue. The organizations that adapt best will not be those that read every advisory manually or patch every system indiscriminately. They will be the ones that build reliable exposure data, automate low-risk enrichment, reserve human attention for judgment-heavy decisions and make remediation a routine platform capability rather than a recurring emergency.