# AI Is Finding Vulnerabilities Faster Than Humans Can Patch Them — And That’s Becoming a Security Crisis

> Source: <https://dev.to/robertadam987_/ai-is-finding-vulnerabilities-faster-than-humans-can-patch-them-and-thats-becoming-a-security-1j04>
> Published: 2026-09-20 04:05:16+00:00

For years, cybersecurity had one obvious problem:

**Finding vulnerabilities was difficult.**

Researchers had to inspect code, reproduce strange behavior, understand systems, and sometimes spend days or weeks finding one serious bug.

AI is changing that.

Modern AI models can now help researchers inspect huge codebases, reason about attack paths, reproduce vulnerabilities, and even suggest fixes.

That sounds like great news.

And in many ways, it is.

But it creates another problem:

**What happens when we can discover vulnerabilities faster than developers can patch them?**

I think this is becoming one of the biggest security challenges of the AI era.

The numbers are already getting difficult to ignore.

By mid-September 2026, more than **66,000 CVEs** had reportedly been recorded — more than double the pace seen in 2025.

Oracle's July 2026 Critical Patch Update was also its **largest security release ever**.

It covered:

Oracle explicitly said the increase reflected, among other things, **AI-powered identification of actionable security findings**.

That is a huge change.

For a long time, security teams wanted better ways to find vulnerabilities.

Now AI is helping provide exactly that.

But discovery is only the first step.

Imagine AI finds a serious bug in your authentication system.

Discovery might take minutes.

But after that, somebody still has to:

**Confirm the vulnerability**

↓

**Understand the affected code**

**Design the fix**

**Check backward compatibility**

**Write tests**

**Review the patch**

**Deploy it safely**

**Monitor production**

**Make sure customers actually update**

That can take hours, days, or much longer.

So we may be moving from:

```
Slow discovery
     ↓
Slow remediation
```

to:

```
Machine-speed discovery
        ↓
Human-speed remediation
```

That imbalance is the real problem.

There is another uncomfortable part.

AI vulnerability research isn't only available to defenders.

Attackers can use similar models to:

Google Cloud has warned about exactly this transition: defenders can use AI to harden software faster, but attackers can also use increasingly capable models to discover and exploit vulnerabilities.

Microsoft makes a similar point.

Its 2026 Secure Future Initiative report says frontier models are helping attackers discover vulnerabilities, chain attack paths, and scale exploitation faster than traditional manual methods.

This changes the race.

The old question was:

**Can an attacker find the vulnerability?**

The new question may become:

**Who finds it first — and who acts faster?**

This is where things become especially difficult.

Google's Mandiant team reported that its 2026 data showed a mean **time-to-exploit of -7 days**.

In simple terms, vulnerabilities are sometimes being exploited **before a patch is available**.

Think about what that means for developers.

You might not be racing against someone manually reading your code anymore.

You could be racing against automated systems continuously searching for weaknesses.

And when a vulnerability becomes public, the time between:

**Disclosure → Exploitation**

may continue getting shorter.

Security teams already have vulnerability backlogs.

Imagine a company has:

```
50 known vulnerabilities
```

and enough engineering capacity to properly fix:

```
10 per month
```

Now introduce AI-assisted vulnerability discovery.

Suddenly the backlog becomes:

```
50
↓
150
↓
500
↓
1,000
```

Finding more bugs is useful.

But only if we can decide which ones matter and fix them fast enough.

Otherwise we create something like:

**Security debt at machine speed.**

When vulnerability numbers explode, developers cannot treat every finding equally.

A CVSS score alone doesn't tell the whole story.

Teams need to ask:

A vulnerability in a public API deserves different urgency from one in an isolated internal test system.

A theoretical vulnerability and an actively exploited vulnerability are not the same thing.

Can an anonymous user exploit it?

Or does an attacker already need administrator access?

Could the vulnerability expose:

If attackers are already using the vulnerability, priority changes immediately.

The goal isn't:

**Patch the highest number of vulnerabilities.**

The goal is:

**Reduce the greatest amount of real risk as quickly as possible.**

This is where I think things become interesting.

If AI creates machine-speed vulnerability discovery, we also need **machine-assisted remediation**.

And that is already starting.

Google recently released **Mantis**, an open-source system designed to help automate:

**Discovery → Triage → Reproduction → Patching**

Google says the system combines agentic techniques with sandboxed reproduction so findings can be verified instead of relying purely on model guesses.

That is important because security AI has another problem:

**False positives.**

An AI model saying:

“I found a critical vulnerability.”

doesn't necessarily mean the vulnerability actually exists.

Google notes that sloppy AI scanning can produce extremely weak true-positive rates.

So the ideal workflow isn't:

```
AI finds bug
    ↓
Developer blindly patches
```

It should be:

```
AI discovers candidate
        ↓
AI reproduces vulnerability
        ↓
Security tooling validates
        ↓
AI proposes fix
        ↓
Tests verify fix
        ↓
Human reviews
        ↓
Deploy
```

That is much more useful.

For software engineers, I think this means security work is going to become less about simply asking:

“Do we have vulnerabilities?”

Almost every meaningful codebase will.

The better questions will be:

**Which vulnerability can actually hurt us?**

**Which one is reachable?**

**Which one is being exploited?**

**Which system contains sensitive data?**

**Which fix carries the least production risk?**

**Which patch should go out first?**

This is prioritization.

And AI can help here too.

This is an important distinction.

If the number of discovered vulnerabilities suddenly doubles, that does not automatically mean developers became twice as bad at writing secure software.

It can also mean:

**Our ability to find existing weaknesses became dramatically better.**

Think about medical imaging.

If a better scanner detects more diseases, that doesn't necessarily mean the population suddenly became much sicker.

We simply became better at finding problems that were already there.

AI may be doing something similar to software security.

That is good.

But discovering hidden problems creates a responsibility to deal with them.

I don't think the answer is panic.

But I do think security processes designed for a slower world need to evolve.

Security checks should be part of CI/CD, not something you remember before a release.

Combine severity with:

Oracle itself is now encouraging customers to move toward a **monthly security patching cycle**.

Organizations with patch processes designed around slow quarterly workflows may struggle as vulnerability discovery accelerates.

If AI finds 500 problems but humans have to manually investigate every one, the system doesn't scale.

AI-assisted reproduction, triage, testing, and patch generation will become increasingly important.

Security patches can break production too.

AI can help generate fixes.

It shouldn't mean:

**AI found it → AI patched it → automatically deploy to production.**

Critical changes still deserve engineering review.

The old security loop looked like this:

```
Researcher finds bug
        ↓
Vendor investigates
        ↓
Patch released
        ↓
Attackers reverse-engineer patch
        ↓
Exploitation begins
```

AI can compress several of those steps.

The future could look more like:

```
AI finds vulnerability
        ↓
AI validates vulnerability
        ↓
AI develops exploit
        ↓
AI proposes patch
        ↓
Humans race to deploy
```

Both sides get faster.

Attackers.

Defenders.

That means the winner may not simply be whoever has the smartest AI.

It may be whoever has the **fastest trustworthy security process**.

For years, we wanted machines that could automatically find security vulnerabilities.

Now we're getting them.

That is a major achievement.

But it creates a strange new challenge:

**What if finding vulnerabilities becomes easier than fixing them?**

The future of application security will not only be about discovering more bugs.

It will be about:

**Prioritizing faster**

**Validating faster**

**Fixing faster**

**Testing faster**

**Deploying faster**

without sacrificing reliability.

Because if AI can find vulnerabilities at machine speed while organizations still patch them at human speed, the vulnerability itself may no longer be the biggest bottleneck.

**Our ability to respond will be.**

**Oracle — July 2026 Critical Patch Update**

Oracle's largest security release to date, covering 1,434 distinct CVEs and highlighting AI-powered vulnerability identification.

**Google Cloud / Mandiant — AI-Assisted Vulnerability Management**

Research on AI vulnerability discovery, exploitation speed, and defensive workflows.

**Google — Mantis**

Open-source AI-assisted vulnerability discovery, reproduction, triage, and patching.

**Microsoft — Secure Future Initiative 2026**

Discussion of AI accelerating vulnerability discovery and exploitation for both attackers and defenders.

**Wired — September 2026**

Reporting on the rapid growth in vulnerability discovery and CVE volume.
