How is known-exploited different from a high CVSS score?

CVSS estimates how bad exploitation would be in theory; known-exploited status confirms exploitation is happening in practice. A high CVSS vulnerability may never be attacked; a known-exploited one is being attacked now. Confirmed reality outranks theoretical severity, which is why known-exploited status is the first sort key, not a tiebreaker.

Where does the known-exploited data come from?

The most widely used catalog is maintained by the US Cybersecurity and Infrastructure Security Agency, which adds vulnerabilities once it has reliable evidence of active exploitation. Other threat-intelligence sources contribute similar signals. In practice the data is consumed as a feed that rides alongside vulnerability information.

Can I use known-exploited data in an airgapped environment?

Yes. The catalog travels inside the signed vulnerability-data bundle you import on your schedule, so your prioritization reflects confirmed exploitation without the scanner reaching the internet - and every report records which bundle version it used, so the state of knowledge at any past scan is reproducible.

What are known exploited vulnerabilities (KEV)?

A known exploited vulnerability is one that has been confirmed to be actively used in real-world attacks. The phrase marks a category shift from most vulnerability data, which is predictive or theoretical: here the exploitation is not estimated or expected, it is observed. That single fact makes known-exploited status the most decisive signal in vulnerability prioritization.

Why “confirmed” changes the calculus

Most vulnerability signals ask you to reason about the future. CVSS estimates how bad exploitation would be; likelihood scores predict whether it will happen. Known-exploited status collapses that uncertainty: attackers are already using this vulnerability against real targets. If you have it, and it is reachable, you are exposed to an attack that is provably in progress somewhere - not a hypothetical.

This is why, in any honest prioritization ladder, known-exploited status is the first sort key. Everything else - severity, likelihood, reachability - orders the vulnerabilities that are not (yet) known to be exploited. The known-exploited set jumps the queue because the argument for urgency is already made.

The catalog

The most widely referenced source is the Known Exploited Vulnerabilities catalog maintained by the US Cybersecurity and Infrastructure Security Agency, which adds a vulnerability once there is reliable evidence of active exploitation. It is deliberately conservative - inclusion means confirmed exploitation, not suspicion - which is precisely what makes it a high-signal, low-noise list. Threat-intelligence providers supply overlapping data, but the shared idea is the same: a curated set of vulnerabilities attackers are actually using.

Using it well

Two practices turn the signal into action:

Top of the queue, always. A known-exploited vulnerability in your environment outranks the wall of high-CVSS findings that may never be touched.
A build gate criterion. Shipping a known-exploited vulnerability should be a deliberate, recorded decision, not an accident. It is also the cleanest possible gate rule - unambiguous, defensible, and hard to argue with - which is why it pairs naturally with deterministic build gates.

In an airgapped program

The obvious worry - that confirmed-exploitation data needs a live feed - does not hold. The catalog travels inside the signed vulnerability-data bundle you import on your own schedule, so an offline program prioritizes against real-world exploitation without any scanner reaching the internet. Because every evaluation records the bundle version it used, you also get something live-feed tools rarely provide: a reproducible record of exactly what was known to be exploited at the time of any past scan. The SecuNexa dashboard uses this signal as the leading term in its queue ordering, entirely offline.