"Have we patched it?" isn't the question your CISO is being asked anymore. AI is finding vulnerabilities faster than anyone can fix them, here's the question that actually matters, and how to answer it before the next zero-day makes the decision for you.
For many years, the rhythm of vulnerability management has been fairly well understood.
A vulnerability is found, a CVE is then issued, the vendor issues an advisory and eventually provides a patch. The security teams identify where the affected technology is, evaluate the severity of the problem, test the update and get it approved through the change control process.
Although it isn’t perfect, everybody understands how the process works.
Attackers don’t have to follow it.
Attackers can exploit a vulnerability before a patch is available. Technical details might still be sketchy, there may be no reliable public proof of concept, and the vendor itself may only just be getting to grips with what has happened. Meanwhile, organizations running the affected software are already being asked a much simpler question: are we vulnerable?
That gap between knowing something is wrong and knowing what it means for your environment is becoming much more important.
AI is adding another complication. It is helping researchers discover and investigate vulnerabilities faster, but it is also increasing the sheer volume of material that vendors, maintainers and security teams have to deal with.
We’ve spent years getting better at managing vulnerabilities once they’re known. The harder problem now is what happens before we have all the answers, and that is where the next shift begins.
The traditional vulnerability management question is usually: Have we patched it?
Increasingly, the question coming from a CISO, CIO, or board is: Can somebody exploit this against us right now?
These are two very different questions.
The 2026 Verizon Data Breach Investigations Report found that 31% of breaches in its dataset began with the exploitation of software vulnerabilities, overtaking stolen credentials as the leading initial access route.
The Google Threat Intelligence Group tracked 90 vulnerabilities that were exploited as zero-days during 2025. Of those, 43 affected enterprise technologies, the highest proportion Google has recorded. Security and networking products accounted for around half of the enterprise zero-days.
This matters because firewalls, VPN gateways, remote-access platforms and other security appliances often have a lot of trust within a network. We rely on them to protect us, but they’re still software, and software can have vulnerabilities.
In some ways, it’s even worse if these devices are compromised. Google points out that many edge technologies don’t have the same monitoring tools organizations use elsewhere, so defenders have less visibility when attackers get in.
The very systems we depend on to protect our networks are often the ones attackers want to control.
Imagine a serious vulnerability starts appearing in threat intelligence.
Your organization uses the affected technology. There is evidence of active exploitation, but the technical detail is limited. No reliable public exploit exists, and there is no patch.
Then the CEO asks the CISO whether the company is vulnerable.
A scanner may tell you the affected software is present. Threat intelligence may tell you attackers are exploiting it elsewhere. Neither necessarily tells you whether an attacker can actually exploit your specific implementation.
Relying on someone online to release working exploit code isn’t a real strategy either.
We saw the consequences of this during the exploitation of on-premises Microsoft SharePoint vulnerabilities in 2025. Microsoft observed attackers compromising internet-facing SharePoint servers and moving on to command execution, credential theft, lateral movement and, in some environments, ransomware deployment.
At that stage, it’s no longer just a routine patching job.
The organization needs to understand whether the vulnerability can be reproduced, whether existing controls make exploitation harder, what an attacker could realistically achieve, and whether keeping the affected service online is an acceptable risk.
The answer won’t always be the same. Additional monitoring or a temporary configuration change might be enough. Isolation may be appropriate. In some cases, switching a critical service off until more is understood could genuinely be the safest option.
Those are business decisions, but someone needs to provide the business with technical evidence it can act on.
This is where offensive vulnerability research is helpful, especially when there are still unanswered questions.
There is plenty of discussion about AI finding vulnerabilities. Less attention is paid to what happens after it finds them.
Somebody still has to reproduce the issue. Somebody has to decide whether it is actually a vulnerability, understand the impact, work out whether the report is a duplicate and, eventually, fix the thing.
The number of reports coming in is rising fast.
HackerOne reported 46,947 vulnerability submissions in March 2026, an increase of 76% year-on-year. Around a quarter of submissions were still considered valid and exploitable, so this increase wasn’t just a flood of useless reports. The number of genuine vulnerabilities reaching defenders also rose significantly.
Remediation hasn’t kept pace, creating a second pressure point.
HackerOne reported a 76% increase in vulnerability discovery, compared with only around a 19% improvement in remediation throughput. That produced a record backlog.
We’ve worked for years to get better at finding vulnerabilities. Now, it’s starting to look like finding them is becoming much easier than fixing them.
GitHub is seeing similar pressure across the disclosure ecosystem. Between January and May 2026, private vulnerability reports on GitHub increased from roughly 550 per week to more than 3,000 per week. Repository advisories rose from around 650 per week to more than 5,000, while GitHub CNA CVE requests approached 4,000 in May alone, nearly ten times the level seen a year earlier.
GitHub described the change plainly:“This is not a localized surge. It reflects structural change across the vulnerability disclosure ecosystem.”
The increased volume has also pushed some advisory processing times from around a week into multiple weeks.
Discovery capacity is growing faster than review capacity.
And that creates another problem.
AI can uncover real vulnerabilities, but it can also generate reports that look good but aren’t accurate.
For people who maintain popular software, this is already turning into a real operational headache.
The curl project is a good example. It has run a vulnerability disclosure and bug bounty program for years and received plenty of genuine security findings through it. During 2025, however, maintainer Daniel Stenberg described an: “Explosion in AI slop reports”
Historically, more than 15% of submissions to curl’s program resulted in confirmed vulnerabilities. During 2025, that figure dropped below 5%. The time spent investigating and disproving poor-quality submissions became significant enough that curl ended its monetary bug bounty program in January 2026.
If somebody can generate ten plausible vulnerability reports in the time it once took to produce one, the cost of submitting a report has fallen dramatically. The cost of properly investigating it hasn’t necessarily fallen at the same rate.
A human still needs to work out whether the issue is real.
While someone is busy checking five convincing but wrong reports, the sixth one in line might be the real problem.
None of this means AI-assisted vulnerability research should be discouraged. The opposite, in fact. Used well, it gives researchers capabilities that would have been difficult to imagine a few years ago.
But as volume rises, signal becomes more valuable.
Having ten thousand findings doesn’t make an organization safer than having ten well-researched ones. If analysts, vendors, and maintainers spend too much time on duplicate, exaggerated, or incorrect reports, they have less time to focus on the vulnerabilities that really need attention.
We can’t claim that every flood of AI-generated reports will cause a critical vulnerability to be missed. There is no evidence for such an absolute statement.
That’s what I think matters most. The scarce resource is changing. Finding vulnerabilities used to be hard and costly, but now high-quality human attention is just as important.
HackerOne itself warns that sending every incoming submission directly into a small human review queue quickly creates a triage bottleneck.
AI has made generating hypotheses and discovering vulnerabilities cheaper.
It hasn’t made human attention unlimited.
There is already good evidence that AI can genuinely contribute to vulnerability research.
Google Project Zero and DeepMind demonstrated this with Big Sleep, which identified a previously unknown exploitable stack buffer underflow vulnerability in SQLite. Google described it as the first public example of an AI agent discovering a previously unknown exploitable memory-safety issue in widely used real-world software.
Their assessment included an important line: “When provided with the right tools, current LLMs can perform vulnerability research.”
GitHub Security Lab has reported similar results. Its researchers identified more than 80 vulnerabilities using AI-powered task flows designed to investigate issues such as authentication bypasses, IDORs, and information disclosure.
One detail in GitHub’s work is particularly relevant: researchers were spending more time manually verifying the findings produced by those workflows.
That’s how I believe this technology should be used: let AI speed up the research, while humans provide the judgment, verification, and context to turn findings into real action.
An AI model shouldn’t be given free rein to decide a piece of client software is vulnerable and start attacking production infrastructure.
It should help a good researcher work faster.
That might mean navigating an unfamiliar codebase, analyzing decompiled functions, comparing vulnerable and patched versions of software, tracing suspicious data flows, developing fuzzing harnesses, understanding patches, or exploring possible vulnerability variants.
They decide where to look and whether a potential issue makes sense in context. They develop the exploitation hypothesis, determine whether the vulnerability actually exists, and decide how to test it safely.
Researchers stay in charge of where the work goes. AI does the analysis faster; a human still has to decide the target is real before anyone touches it.
That’s the trade-off: more speed, but experience and judgment don’t get to retire.
Attackers will get the same benefits, of course.
Google Threat Intelligence Group expects AI to accelerate reconnaissance, vulnerability discovery and exploit development, reducing the time defenders have to respond.
As Google puts it: “AI will accelerate the ongoing race between attackers and defenders.”
There’s no need to make this sound like science fiction. Not every attacker is suddenly using an autonomous, super-intelligent hacking tool.
They don’t need to be.
If AI helps a capable exploit developer understand a codebase faster, automate repetitive work, generate useful test cases, or examine more potential attack paths, their research cycle shortens.
Google is already observing advanced actors developing and distributing exploits more quickly, contributing to a shrinking gap between public disclosure and broader exploitation. Microsoft has reported the same general trend, with threat actors incorporating exploits for known vulnerabilities more quickly and putting more pressure on the period between disclosure, patch availability, and actual deployment.
Defenders have to work inside that window as well.
None of this makes vulnerability management obsolete.
Knowing what assets you have still matters. Prioritization matters. Patching matters. CISA’s Known Exploited Vulnerabilities catalog exists for good reason, giving organizations a way to focus on vulnerabilities with evidence of exploitation in the wild.
The limitation is that vulnerability management works best once enough information exists to understand what you’re dealing with.
There is a growing area around that process where organizations need something different.
Threat intelligence may tell you something is happening.
Asset inventory tells you that you run the technology.
A vulnerability platform tells you that you could be affected.
None of them necessarily answer: Can an attacker actually use this against us?
To answer that properly, somebody has to do the research.
The worst time to begin understanding an important technology is the evening it appears on the front page of every security news site.
A continuous research capability can start much earlier by concentrating on the technologies an organization actually depends upon.
Internet-facing infrastructure can be mapped and prioritized. You can investigate high-value technologies at the software, firmware, and protocol level. In some cases, that research may uncover previously unknown vulnerabilities, but there is another benefit that is easier to overlook.
If a VPN platform, firewall or security appliance suddenly becomes the subject of an emerging zero-day, the research team may already understand how the product is put together. They may have looked at its attack surface, its components and some of its internal behavior.
They’re not starting from scratch at the same time as everybody else.
When evidence of active exploitation appears, that same capability can switch from proactive research into rapid exposure validation.
Researchers dig into the intelligence, pull the product apart, and reverse-engineer the components that matter. Then they work out what the attacker actually found and, where they can, build a safe, private proof of concept to demonstrate it.
The point is to answer the questions the organization actually cares about:
Are we exposed? Can it be exploited in our environment? What could an attacker achieve? What should we do now?
This approach is less like a standard penetration test and more like having an offensive incident response team on standby. When something serious happens, the organization already knows who will handle the investigation.
And the work shouldn’t automatically stop when the patch arrives.
Patches are useful research artifacts. Comparing vulnerable and fixed versions can reveal exactly what changed and help establish the root cause.
Sometimes that confirms the vulnerability has been properly resolved.
Sometimes it shows that you’ve fixed one attack path while the wider weakness remains. Similar vulnerable code might exist in another component. A workaround might be bypassable. The original issue may have closely related variants.
Google Project Zero has repeatedly highlighted vulnerability variant analysis as an important research area because attackers have found exploitable variants of vulnerabilities that were supposedly already understood and patched.
So instead of thinking about the lifecycle as:
Discover. Patch. Done.
A more useful model is:
Before it is known. While it is being exploited. After it is patched.
A Constant Cyber Attack subscription is built around exactly that lifecycle.
It isn’t intended to replace penetration testing, vulnerability management, threat intelligence or incident response. Those capabilities already solve important problems.
The Swarm sits between them.
During normal operations, the Swarm investigates the technologies that matter most to an organization and identifies weaknesses before they become public.
When a significant zero-day emerges, that same research effort pivots to rapid analysis and validation of exposure.
Once a mitigation or patch becomes available, the Swarm can independently determine whether it actually addresses the risk and identify related variants.
AI lets our researchers do more and spend less time on repetitive analysis, but humans still lead the work.
That distinction will matter more as vulnerability discovery scales.
In the future, the problem might not be a lack of findings, but having far too many.
More reports. More alerts. More generated hypotheses. More vulnerabilities sitting in queues waiting for a limited number of engineers and researchers to understand them.
At that point, another scanner telling you that something might be vulnerable isn’t necessarily what you need.
You need somebody who can prove what actually matters.
When the next serious vulnerability emerges, the CISO probably won’t be asked for its CVSS score.
They’ll be asked: Are we vulnerable?
Then: Can someone exploit us?
And very quickly: What are we doing about it?
The security industry has developed mature processes for answering those questions once a vulnerability is understood and a patch is available.
The difficult part is answering them when neither is true.
AI is also making vulnerability research bigger and faster. That helps defenders, but it adds noise and remediation pressure too, and makes it much harder to tell which findings actually matter.
More automation for its own sake doesn’t solve that.
Better research might.
Human researchers, using AI where it gives them an advantage, concentrating on the technology that actually matters to the organization and turning uncertainty into evidence.
Because when a serious vulnerability is being exploited and there’s no patch, saying “we don’t know yet” often isn’t good enough.
This is already how a Constant Cyber Attack subscription works. Contact us to see the Swarm’s research running before the next zero-day appears.
This article draws on primary research and industry data from Google Threat Intelligence Group’s 2025 Zero-Days in Review, Google Project Zero and DeepMind’s From Naptime to Big Sleep, GitHub Security Lab’s AI-assisted vulnerability research, GitHub’s analysis of record vulnerability disclosure volume, HackerOne’s 2026 vulnerability submission and remediation data, the curl project’s account of AI-generated security-report volume, Microsoft’s analysis of active SharePoint exploitation, the 2026 Verizon Data Breach Investigations Report and CISA’s Known Exploited Vulnerabilities program.