How to prioritise CVEs by real exploitation, beyond CVSS, EPSS and KEV

By Thibault Koechlin, CTO at CrowdSec

Log4Shell has a CVSS score of 10. As of this writing, our network gives it a 3.

Meanwhile, a remote code execution in BeyondTrust’s remote support product scores 9 on the same scale: attackers are picking their targets carefully, and activity is above average. So you have both on your patch list and a single maintenance window: which one goes first?

Here’s the short answer: prioritise by what attackers are doing right now. Is the CVE exploited at all? Are attackers choosing their victims or spraying the whole internet? Is the activity growing or fading? CVSS, EPSS and KEV give you the theory and the history. Live exploitation data gives you today’s order.

Back to Log4Shell: the folks still scanning for it today are more likely to be laggards, CERTs or pentesting companies than real bad guys. The really dangerous exploitation happens in the first hours and days after release: it’s the same window CISA now works with, since BOD 26-04 gives US federal agencies 72 hours to fix publicly exposed, highest-risk exploited vulnerabilities. And if Log4Shell is still an issue at your workplace in 2026, well, digital Darwinism will kick in fairly quickly 😅

What CVSS, EPSS and KEV actually tell you

All three are useful. They just answer a different question than “what should I patch first this week?”

• CVSS rates how bad a vulnerability could be, from its technical characteristics (attack vector, complexity, impact). It’s set at disclosure, so a 10 stays a 10 years after the attackers have moved on.
• EPSS estimates the probability that a vulnerability gets exploited in the wild in the next 30 days. It’s much closer to reality, but it’s a probability across everyone: it says little about who is being hit, or how. Don’t get me wrong, EPSS is useful: it’s a good complement to the existing scores.
• CISA KEV lists vulnerabilities with evidence of exploitation in the wild. Great for “must patch” lists, but it’s a yes/no with no sense of intensity or trend, and entries land after the evidence. The most important part, to me: things get added to KEV and practically never removed, so you end up with an ever-growing list, long after the attackers have moved on.

Do any of them tell you whether attackers are going after organisations like yours this week? No, and that’s the gap we wanted to fill.

Three signals that set the order

When we built the Live Exploit Tracker, we boiled exploitation down to three questions, each answered from the more than 40 million attack signals a day sent by 250,000+ active Security Engines.

1. Is it exploited now, and by how many IPs? Plenty of scary CVEs see little real exploitation, while some boring-looking ones get hammered. Counting the distinct IPs that exploited a CVE over the last few days is the first filter.

2. Targeted or mass scanning? We call this the Targeted score (0 to 5). At 0, attackers hit IPs at random in automated sweeps: you’re one of millions. At 5, they select their victims based on exposure and configuration, and an alert on your systems likely means someone picked you. CVSS is blind here: a CVSS 7.5 hunted precisely can hurt you more than a CVSS 10 nobody bothers with.

3. Growing or fading? The Momentum score (0 to 5) compares current volume with the CVE’s history. High momentum with low targeting usually means a new automated campaign: lots of noise, little signal per alert. High momentum with high targeting is the combination that should get you out of bed.

The tracker folds these into a CrowdSec Score from 0 to 10, and adds an exploitation phase, a plain-language label for where the CVE sits in its life. For a fresh CVE, things move fast:

Around	Phase	What it means for you
day 0	Insufficient data	Too early to tell: fall back to CVSS and the vendor advisory
day 1	Early exploitation	First scans and small-scale attempts, often right after a public PoC: start prioritising
by day 2	Rapid escalation	Several actors weaponise it, volume climbs fast: patch now, block proactively
within weeks	Active exploitation	Exploited at scale by automated campaigns: emergency if you’re still exposed
after months	Background noise	Part of the internet’s weather: patch in your normal cycle, filter the noise

Does every CVE follow that path? No, and that’s precisely why we watch it live.

From score to decision

Here’s the triage table we use in our own docs, slightly condensed:

What you see	What to do
High score, targeted, growing	Emergency patch, block the exploiting IPs now, look for signs of compromise
High score, active exploitation	Urgent patch, block, check every instance of the affected software
Moderate score, background noise	Patch within days rather than weeks; blocking is optional
Low score, limited exploitation	Normal patch cycle, watch for a phase change
Insufficient data	Use CVSS and the vendor advisory, check back later

Two more signals help break ties. The threat context tells you who is being targeted: attacker and victim countries, industries, and what the attackers seem to want (taking over infrastructure, stealing data, ransomware). And reconnaissance rules catch attackers probing a product (Exchange, F5, WordPress…) before any CVE is published, which often tells you where the next wave will land.

An example from our docs: for an authentication bypass in PAN-OS, the threat context showed mostly commercial and tech companies being targeted, with French and Hungarian organisations over-represented, and attackers going after control of the firewall management plane instead of data. If you run that product in a French tech company, that CVE goes to the top of the pile, whatever its rank in your scanner.

Block while you patch

Patching takes time, and some systems simply can’t be patched this week. The tracker lists the IPs exploiting each CVE, and you can subscribe a firewall to that list by CVE or by vendor (which also covers the vendor’s future CVEs). It works with Palo Alto, FortiGate, Check Point, Cisco, Juniper, Sophos, F5, pfSense, OPNsense, MikroTik, or any device that reads a plain IP list.

Large SOCs are rightly wary of broad blocklists they don’t control. A list scoped to the IPs exploiting the one CVE you can’t patch yet is an easier conversation, and it buys you time to patch properly.

What it can’t see

Is this a replacement for your vulnerability scanner or for CVSS? No. The tracker shows how a CVE is exploited in the wild; your scanner shows where you’re exposed. And we only see what hits internet-exposed systems: for products that are rare in our network, a CVE can sit in “insufficient data” for a while. The right move then is to fall back on CVSS and the vendor’s advisory until the data matures.

Try it

• Look up any CVE in the Live Exploit Tracker (book a demo to get your access key), or pull scores, phases and attacker IPs through the API and the Python SDK into your SIEM, SOAR or vulnerability-management workflow.
• For the bigger picture, our vulnerability and exploitation report covers the trends behind these scores.

Spotted a CVE whose score surprised you? Let us know on Discord: that’s how the scoring gets better.