CVSS Exploit Maturity values: Attacked, POC, Unreported, Not Defined

Exploit Maturity is the only Threat metric in CVSS 4.0. It has four values: Attacked, Proof-of-Concept, Unreported and Not Defined. You set it, not the vendor, using threat intelligence. If you leave it unset the score assumes Attacked, so real data can only keep a score where it is or bring it down.

The four values

The specification defines each one from the evidence available:

• Attacked (A): attacks on this flaw, attempted or successful, have been reported, or tools that simplify exploitation, such as exploit kits, are available publicly or privately.
• Proof-of-Concept (P): public proof-of-concept code exists, with no knowledge of reported attacks and no simplifying tools.
• Unreported (U): no public proof-of-concept, no reported attempts and no simplifying tools.
• Not Defined (X): reliable threat intelligence is not available. This is the default and is scored like Attacked.

Note how "attacked" includes attempts, not only successes. That matches how CISA treats active exploitation for its KEV catalog, where attempted exploitation counts too.

Why the consumer fills it in

The FAQ answers this head on. If suppliers owned the metric, every vendor would need a real-time view of exploit status for every flaw they ever announced. That is neither realistic nor reliable. Threat intelligence providers do this work, and many feeds are free or inexpensive.

Vendors score for the reasonable worst case and assume every flaw will be fully weaponized. Consumers then apply what is known. A flaw with no exploitation and no public proof-of-concept falls in score. An exploited flaw stays high.

Why it only lowers the score

This surprises people. The FAQ explains that if the most dangerous flaws already score 10, there is no room above them. Scoring base values lower to leave headroom would mean no flaw could be Critical until threat data was applied. So the design starts high and lets evidence pull the number down.

The upshot: a CVSS-B 9.3 is a ceiling, not a forecast.

Where to get the data

The specification's operational advice is direct. Prefer sources that cover all vulnerabilities over partial ones. Use several sources, since many are not comprehensive. Update as often as possible and automate the application. The FAQ suggests daily refreshes.

Reasonable inputs include:

• the CISA KEV catalog for confirmed exploitation
• the EPSS daily file for likelihood over the next 30 days
• public exploit repositories for proof-of-concept status

If your sources use a different vocabulary, you will need a mapping, and the FAQ notes this translation may be required.

A mapping you can write down

Here is one defensible mapping for a team starting out. Anything on KEV maps to Attacked. Anything with a public exploit but no KEV entry maps to Proof-of-Concept. Everything else maps to Unreported, unless your feed gives you no information, in which case leave it Not Defined and accept the high score. Write the rule in your vulnerability management policy so reviewers know where the value came from.

Safeguard checks reachability and fix availability alongside exploitation signals. The exploitability check demo shows the idea.

Quick check

Sources

• FIRST: CVSS v4.0 Specification Document
• FIRST: CVSS v4.0 FAQ
• CISA: Known Exploited Vulnerabilities criteria

Last reviewed: 19 October 2026.