Ryan Dewhurst, CEO at KEVIntel, explains how his team confirms exploitation that CISA’s catalog has not listed yet. He describes a global honeypot sensor network, AI triage, and human verification in a lab before a vulnerability reaches the public feed.
He covers CISA’s three-day patching deadline under BOD 26-04, why virtual patching buys time, and how AI-generated proof-of-concept code muddies the evidence. He also ranks incident reports, honeypot hits, scanning and PoC chatter by how much each should move a defender’s confidence.
CISA’s catalog carries a remediation deadline for federal agencies, so adding an entry is a policy act as much as a technical one. How should a security professional from the private sector read a list assembled under those pressures?
For the private sector, CISA KEV is an authoritative exploitation signal source. But it should not be considered as a complete definitive list of KEVs. We also can’t ignore that CISA is a relatively large organization, which can affect the speed at which it operates. And that it is biased to US federal agencies.
CISA’s recent BOD 26-04: Implementation Guidance for Prioritizing Security Updates Based on Risk directive, which was issued on June 10, 2026, federal agencies will have just three days to address actively exploited KEVs, which are automatable and affect Internet facing assets.
This new directive reinforces the fact that organizations should be prioritising high risk KEVs first. Today, on average, there are around 200 CVEs released per day, and this is increasing year on year, especially with the advent of AI. It is practically impossible to patch all vulnerabilities, or even just the Critical and High vulnerabilities.
Patching a vulnerability in just three days is ambitious. Patch management has to go through lots of stakeholders and is usually managed by a change management team. Just figuring out what assets you have and who owns them can sometimes be a lengthy process, especially if the organization does not have effective asset management in place.
What organizations need is more time. But attackers are not waiting. We’ve seen them move faster and faster, using AI to reverse engineer patches and weaponize vulnerabilities in record time.
One solution to this problem is virtual patching, usually a WAF rule designed to block the attack whilst the organization patches the vulnerable devices. For example, we have seen these used effectively recently by providers to reduce exposure to the WordPress Core RCE chain. Virtual patches are not a long term solution, they are not perfect, and should only be used to buy more time, while patching takes place.
Vendors have reasons to both inflate and suppress exploitation claims. Which direction do you see the pressure pushing hardest right now, and who pays for it?
It really depends on the vendor. We have seen vendors who inflate a vulnerability’s risk, while others try to downplay them. For example, on the downplaying side, we’ve seen vendors claim a vulnerability is only exploitable with authentication, and then, when looked at more closely, it turns out that it can actually be exploited by anonymous unauthenticated users. Or, claiming that the vulnerability has not been exploited in the wild, but they also include incident derived IoCs in their advisory. A huge red flag.
Ultimately, it’s the vendor’s customers who pay the price. Eventually, the full details usually come to light. Meanwhile, attackers are taking full advantage of the confusion and customers have to play catchup.
What is the most convincing false positive you have chased: something that looked like live exploitation and turned out to be noise, and what did it teach you?
We see this quite often. A lot of “researchers” will pass the limited available vulnerability details to an LLM and ask it to generate a PoC. The AI will do its best to create a PoC with the limited information given, but the resulting code doesn’t actually exploit the vulnerability, it just looks convincing enough to satisfy the researcher. This can happen tens of times for one vulnerability, making it difficult to distinguish what’s “AI-slop” and what’s a real working exploit.
Recently, we saw this with CVE-2026-25089, an OS Command Injection vulnerability in Fortinet FortiSandbox.
For example, our sensors will pick up on the novel exploitation and flag it to us, but then we have to spend time researching and trying to reproduce the vulnerability to determine if it’s “AI-slop” or not.
And it is sometimes very difficult to tell from the attacker telemetry itself. The PoCs often use the correct target software and correct vulnerable endpoints.
Often, the obvious giveaway doesn’t lie in the technical details, but more in how the PoC’s documentation is written, is it AI written? Or, is this a reputable researcher? Have they released false PoCs in the past, or are they a seasoned researcher with lots of experience and a good reputation?
These are easy tell tale signs, but ultimately, technical reproduction of the vulnerability is the ultimate deciding factor.
Honeypot hits, internet-wide scanning, PoC chatter, incident reports. Rank those by how much they should move a defender’s confidence and name the one that gets over-trusted.
1. Incident reports
These are great because they often contain a lot of technical details, attacker tradecraft and IoCs that defenders can use to help mitigate the attacks. But, on the flip side, this also means active exploitation is already taking place.
2. Honeypot hits
If we see exploitation in our honeypot sensors that has been validated to be genuine exploitation (a KEV), this should be a priority for defenders. An attacker is actively targeting the vulnerability and attempting to exploit real devices on the Internet. You could be next.
3. Internet-wide scanning
It depends what we mean by “scanning”. Active internet wide probing data can have some benefits. For example, we often see a spike in probes before exploitation takes place.
Then, we often see Internet wide mass exploitation after targeted exploitation has taken place. Exploitation will often start highly targeted, just a few attempts against the vulnerable software. But after a while, we’ll start to see attackers indiscriminately scanning every device on the Internet.
4. PoC chatter
These are often over trusted. PoC chatter can be helpful. But as we discussed previously, we have to be careful what to trust. A PoC from an existing scanner, such as Nuclei, Nessus, Metasploit, is usually trustworthy. Whereas some random guy putting up AI generated PoCs on GitHub should be taken with a grain of salt.
KEVIntel has flagged hundreds of exploited CVEs that never showed up in CISA’s catalog. When you find one of those gaps, how do you satisfy yourself that you’re right and the government list is lagging?
At the time of writing, we have added over a thousand CVEs that are not currently included in the CISA KEV catalog. The way we detect new Known Exploited Vulnerabilities (KEVs) is by using our proprietary global honeypot sensor network, and also by monitoring reputable online sources, such as vendor advisories, and researcher blogs.
We satisfy ourselves that we’re right by confirming exploitation through our sensor network.
We deploy our sensors globally, in many different countries and regions, such as in Australia, Canada, Europe, the USA, the Middle East and more. Where possible, our sensors are real applications or devices that sit on the Internet and record how attackers are attacking them.
When our sensors detect a novel attack, the first phase is to use AI to help determine whether it is a known vulnerability, an unknown vulnerability, or just random Internet probing. With the right prompts and guardrails, frontier AI models have become very good at this.
The AI result is then passed to a human security researcher who manually verifies the AI’s findings. Does this match known PoCs, is the CVE attribution correct, can this attack be replicated in a lab?
Finally, once the security researcher is satisfied that the attack is a true positive, a detection is created from the attacker telemetry, so that all past and future attack data is forwarded on to our KEVIntel platform.
In other cases, where the exploitation is very targeted, say against just one software vendor’s customer, the vendor will often disclose this to the public, along with Indicators of Compromise (IoCs). In these cases, where we haven’t yet seen attacks in our own sensors, but the evidence is sufficient and comes from a reputable source, we will add the vulnerability to our public KEV feed and monitor for exploitation in our sensors.
Demo: Prophet Agentic AI SOC Platform transforms alert triage and investigation