Reading CVSS vectors next to KEV: what CISA's documents say

What these documents cover, and what they leave out

The question has two parts. The first asks what the CVSS base metrics mean, including confidentiality, integrity and availability impact. The second asks how to read a CVSS vector next to a CISA Known Exploited Vulnerabilities (KEV) listing.

The three CISA documents behind this briefing do not answer the first part. They are an alert on PHP vulnerabilities and two KEV addition notices, dated October 28, 2026 and October 30, 2026. None of them defines a CVSS base metric, shows a CVSS vector, or gives a score. This guide therefore does not define the metrics. A definition would have to come from the CVSS specification or from the scoring record for a given CVE, and neither is among the documents.

What the documents do show is how CISA frames priority when a CVE is on the KEV list. That is the useful half of the question, and the rest of this guide sticks to it.

What a KEV listing is, according to CISA

CISA's two addition notices open with the same sentence, which says a listing is based on evidence of active exploitation. So a KEV entry rests on evidence that attackers are using the flaw.

CISA also states three criteria that a nominated vulnerability needs to meet. Those three items are the entry criteria. Severity is not one of them.

The notices also give CISA's reason for caring about these entries.

How BOD 26-04 sets priority

Both KEV notices describe Binding Operational Directive 26-04, "Prioritizing Security Updates Based on Risk." The directive is the closest thing in these documents to a rule for combining a KEV listing with other facts about a vulnerability.

CISA says the directive requires federal agencies to prioritize rapid remediation of high-risk vulnerabilities. Per the notices, these are vulnerabilities in the KEV Catalog on publicly exposed assets where exploitation grants total control, while action is deferred for lower-risk vulnerabilities.

That sentence has three conditions, and all three are needed for the highest priority:

• The CVE is in the KEV Catalog.
• The asset is publicly exposed.
• Exploitation grants total control of the asset.

The directive also covers what happens before the patch. CISA says systems may have been compromised before the patch was applied. In CISA's framing, patching and checking for compromise are separate steps.

On who is covered, CISA writes that federal agencies are required to prioritize remediation of KEV Catalog vulnerabilities.

A worked case: the PHP alert

CISA's PHP alert shows those conditions applied to one real set of CVEs. The alert is dated October 23, 2026 and was revised on October 26, 2026. It covers CVE-2026-109618 and CVE-2026-109619.

CISA describes the impact in plain language, not in metric terms. The flaws, which it calls "php2shell," affect PHP-FPM, php-cgi, FrankenPHP and LiteSpeed. That is the language of total control: code runs on the host and no login is required. The alert never maps it to confidentiality, integrity or availability ratings.

On timing, the alert says the CVEs were later added to the KEV Catalog. This was three days after the October 23 revision, which means the alert's "immediate patching" language came before the KEV listing. The documents do not say why the listing came later.

The fix is stated directly.

CISA's actions apply the exposure condition. The alert sets out actions for exposed systems. It also warns about finding the affected systems.

For systems that cannot be updated, the alert is firm about what to do. It adds a limited mitigation.

For detection, CISA gives specific steps. That matches the directive's point that systems may have been compromised before the patch was applied.

Other KEV entries show that vulnerability type varies

The October 28, 2026 notice lists two entries. The first is named in the notice. The second is named there too.

The October 30, 2026 notice also lists two. The first is named in the notice. The second is named there too.

These names describe the kind of weakness, such as insufficient logging or a predictable identifier. The notices do not say what an attacker gains from any of them. They give no score or vector for any of the four entries, and they do not rate any one above another. Judging each entry on exposure and post-exploitation control would need facts from outside these documents.

What this means for reading a vector beside a KEV listing

Taken only from these documents, the relationship works as follows.

A KEV listing answers a question about the present: has exploitation been observed? CISA's criteria say it requires evidence of exploitation. The documents do not say whether a CVSS vector can answer that question.

CISA's own highest-priority test in BOD 26-04 asks about exposure and about whether exploitation gives total control of the asset. The documents do not say how CVSS impact ratings relate to "total control." A leader who wants to use a vector for that test would need a source that connects the two. These documents do not supply one, and this guide will not guess at it.

The documents also set a limit on how CVSS and KEV fit together. They never describe a case where a vulnerability is on the KEV list and looks lower-risk, or the reverse. The directive's wording on deferring "lower-risk vulnerabilities" is the only statement about vulnerabilities that are not top priority, and it does not say how to judge them.

For the CVSS definitions themselves, go to the CVSS specification and the scoring record for the CVE in question. For KEV, the CISA documents above are enough to say what a listing means and how the directive uses it.