A known exploited vulnerability is a flaw that has evidence of attackers actually using it, not just a theoretical weakness. Tell leaders that this changes the question from "could this be used against us" to "is this being used right now", which is why such flaws jump the queue.
The plain explanation
"Most flaws we find have never been seen in an attack. A smaller group has. CISA keeps a public catalogue of vulnerabilities with evidence of exploitation in the wild. If a flaw in our software is on that list, someone has already built and used a working attack. We treat those first."
Notice what is left out: scores, vectors and acronyms. Leaders need the reason for the priority, not the scoring system.
Why it outranks a high score
| Signal | What it tells you |
|---|---|
| Severity score | How bad the flaw could be in general |
| Exploited in the wild | Attackers have used it, so the effort to attack is already paid |
| Present in your software | Whether you hold the flaw at all |
| Reachable and exposed | Whether an attacker could use it against you |
A flaw with a moderate score and confirmed exploitation can deserve more urgency than a critical score with no known attacks. Exploitation is evidence about attacker behaviour. A score is an estimate about the flaw.
That said, exploitation evidence is not the sole factor. If you do not run the affected software, or it is not exposed, the catalogue entry does not apply to you. The first task is always to check presence and exposure.
What to ask leaders for
Keep the ask small and specific.
- A shorter deadline for this class. For example, a written target for flaws with evidence of exploitation, shorter than the routine cycle.
- A named owner for each affected system. So there is no debate about who acts.
- Permission to accept a short disruption. A patch window or restart may be needed outside the normal schedule.
What to report back
Give a simple status: how many such flaws apply to us, how many are fixed, and how many are in progress with a date. If none apply, say so. "None of the entries added this month affect our software, and here is how we checked" is a useful message that builds trust.
Common questions from leaders
"Are we being attacked?" Not necessarily. The catalogue shows attacks occurred somewhere. Your exposure determines whether you are a target.
"Why not patch everything this fast?" Speed carries its own risk of breakage. Reserving the fast path for exploited flaws keeps the rest of the work safe.
"How do you know it is on the list?" The catalogue is public and can be checked automatically against your software inventory.
Try it yourself
Click through the zero day watch demo and see how newly disclosed issues are matched against what you run.
Click through it at your own pace, or open it full screen.
Safeguard's zero-day discovery and SBOM and dependency scanning help answer "does it apply to us". The free scan at gold.safeguard.sh/scan is a first step.
Quick check
Is a flaw in the exploited catalogue always urgent for me?
If you run the affected software and it is exposed. Check presence and exposure first.
Does a missing catalogue entry mean a flaw is safe?
No. It means evidence has not been recorded there. Use other signals as well.
Sources
Last reviewed: 19 October 2026.
