Report Review: VulnCheck's 1H 2025 State of Exploitation Report
Conclusion: Defenders should read the first 3 pages! (5 minute read)
I have a lot of grand plans for this Substack, and one of them is reviewing reports as they come out, so my readers have a better idea of which are worth a read. The subtitle of each of these writeups will give you my conclusion, so you don’t even have to read my take to know how I feel about it!
Context
VulnCheck is a vulnerability/exploit intelligence vendor that publishes a lot of really interesting research and have a lot of useful free tools. They have their own expanded version of CISA’s KEV, which has a free mailing list. Lots of free tools as well. All-around a good resource.
Patrick Garrity specializes in interesting research and spicy takes on LinkedIn, which sometimes challenges the takes of other vuln-focused firms. I have friends on both sides of these takes, so while I try to stay neutral the best I can, I honestly don’t mind the drama, as long as it results in better quality intelligence that can help defenders.
Steel sharpens steel or something? Whatever, let’s dive into the report.
Report Details
Patrick has shared the report in a LinkedIn post, which is a great opportunity to read it before it gets put behind a reg wall. I don’t know if this means this LinkedIn post will get removed later, or if this is just a portion of the full report - I’ll try to come back to this post and update it if things change.
The report is only 9 pages with a lot of graphics, so this is a quick read. Moreso if you’re not interested in exploitation discovery sources (page 4), threat actor attribution (pages 5-7) , or industry performance (page 8).
Insights
VulnCheck identified 432 CVEs with evidence of exploitation in the wild for the first time
KEV lists are useful for prioritization. CISA KEV and VulnCheck KEV are useful tools for vuln teams to prioritize their work. 432 sounds like a big number, but consider that every organization doesn’t have every vendor on the list here, so the vulns they’ll have to worry about is likely to be a small subset of this number, probably less than 100.
KEV lists are late indicators. By definition, a vuln doesn’t make a KEV list until it’s already being exploited. Don’t get me wrong, late is better than nothing, but if you’re waiting for a vuln to get on a KEV list before remediating it, you might be waiting far too long.
KEV lists sometimes beat CVE publication? This is problematic, given that some vulnerability management programs depend on CVE publication before the wheels of remediation even start turning. I need to put out a dedicated post on this to explain further, but modern vuln mgmt teams need to implement intel-driven vuln mgmt processes in addition to their scan-driven processes. A scan-driven process is much less likely to get vulns fixed before exploitation occurs. In addition, it is becoming clear that intel-driven processes should trigger at the point the vulnerability is disclosed, which could be pre-CVE, pre-CVSS, and pre-KEV, so this process can’t afford to depend on any of these things.
Lots of good insights about the speed of exploitation. For example, 32.1% of KEVs had exploitation evidence on or before the day the CVE was issued, increasing from 23.6% in 2024. This number is high enough to again justify the intel-driven approach described in my last point above.
Open source software is statistically less targeted than commercial software
Vulns in network edge devices and CMS plugins dominate the KEV list, which is no change from the norm - there are two distinct places we see exploit activity clustered: for an initial foothold (Internet-exposed services with RCE exploits) and internal systems during lateral movement (internal unsegmented networks with lagging patches, vulnerable to RCE exploits).
A note in the increase of IoT device vulns, which makes sense, given the continued interest in building IoT-based botnets for DDoS attack rentals, like the Oregon resident that was recently charged for building and renting out Rapper Bot - a botnet similar in construction and destructive power to Mirai.
There’s threat actor detail, though I think this is less interesting to defenders, as the goal is not to get popped regardless of who is behind the exploit activity. Note to self: Why doesn’t the US ever show up on these threat actor reports? Investigate this for a future report, Adrian.
Gripes
The separation between zero day vuln exploitation and exploitation of older vulns is a bit fuzzy for me throughout this report. I think it could have been made more clear. In some places, like the excellent ‘How quickly are Vulnerabilities Being Exploited’ chart, it is quite clear.
What does “exploitation in the wild” look like? Does that mean that the exploit was attempted? Did it succeed? Did it result in a breach, or damages? These are questions I need to dive deeper into in a dedicated post. In the past, I managed to get a CVE to show up as “exploited” on a threat intel provider’s dashboard simply by sending a tweet with the CVE number in the text of the tweet. I worry about the quality of exploit evidence sources when providers say they have a large number of them. On the other hand, when you’re driving the number of vulns you have to worry about to just a few hundred, just assume you could get hit by any of these and forget about my nitpicky concerns for now ;)
One point left me a bit confused: 147 of 181 unique CVEs that were used by known threat actors had evidence of exploitation prior to 2025, demonstrating that threat actor exploitation disclosure often lags behind disclosure of initial exploitation evidence. Maybe this is saying that attributing exploit activity to threat actors is hard and takes time?