What Happened
Microsoft’s analysis found that 2,056 of roughly 383,000 CVEs disclosed from 1999 through September 2026 were linked to exploitation in the wild—about 0.5%. Vulnerabilities enabling system takeover, including remote code execution and privilege escalation, accounted for 78% of exploited CVEs. In 2025, 29% of observed exploits launched within a day of CVE publication [2].
Unit 42 reports rapid adoption of AI across offensive workflows alongside continuing cyberespionage and financial extortion. That observation signals a changing threat environment, but does not quantify how much AI increases attack speed or success [1]. On defense, Trail of Bits reports using Codex to identify and adapt security backports, run tests, and prepare evidence for human review. By October 29, that work had helped deliver fixes for 149 distinct CVEs to stable Linux kernel releases [3].
Why It Matters to Businesses
Severity alone is a poor work queue. A critical finding on an unreachable asset may be less urgent than an actively exploited takeover flaw on an internet-facing service. Prioritization needs asset exposure, evidence of exploitation, likely impact, and the blast radius of a compromise [2].
AI-assisted development can reduce the labor of maintaining older software, but it does not remove the need for regression tests and maintainer acceptance [3]. Businesses adopting such tools need to secure both the software being patched and the workflow that proposes changes.
Kimbodo Engineering Perspective
We would use AI to accelerate analysis and produce reviewable patch candidates, not to authorize production changes. The useful boundary is clear: an agent may inspect code, propose a backport, and run constrained tests; a responsible engineer decides whether the change preserves behavior and can be released. Trail of Bits’ results support that division of labor, rather than a claim of autonomous patch safety [3].
For vulnerability management, we would combine exploitation signals with a verified inventory and attack-path analysis. Microsoft recommends identifying reachable assets and breaking paths to high-value systems rather than relying on severity scores alone [2].
How We Would Implement It
- Maintain an inventory connecting deployed versions, internet exposure, service ownership, and critical dependencies. Match new CVEs to assets actually running affected code.
- Rank remediation using observed exploitation, reachability, takeover potential, privilege gained, and blast radius. Record the reason for each priority decision [2].
- Run patch-assistance agents in isolated, least-privilege environments with restricted network access. Treat repository content and tool output as untrusted input; require approval before an agent can access secrets or publish changes.
- For each proposed backport, retain the upstream fix, patch diff, test results, and compatibility rationale. Require human review, regression testing, and staged deployment with rollback [3].
- Track time from disclosure to exposure assessment, mitigation, and verified deployment. Prioritize compensating controls when a tested patch cannot be shipped quickly.
Risks, Costs and Security
The 0.5% historical exploitation figure is not a prediction that any particular new CVE is safe to defer. Exploitation can begin before a normal patch cycle is complete, and incomplete asset visibility can make an exposed system appear irrelevant [2].
AI-generated patches may compile while subtly changing behavior. Isolated execution, reproducible tests, code review, and deployment controls add cost, but are necessary checks on that risk. Agent permissions also need tight limits: a prompt or repository file should not be able to turn a patching task into credential access or an unreviewed release. The practical goal is faster, auditable remediation—not replacing security engineering judgment [3].
Where Kimbodo Comes In
Kimbodo builds and operates this in production for businesses — see our AI Security & Guardrails practice, or Request a Security Review.
