Matching KEV alerts to your asset inventory: product names, CVE IDs and CPE strings

What a KEV alert gives you

A KEV addition arrives as a short line, and the matching work starts from that line. The four CISA pages we reviewed are dated October 23, 26 and 27, 2026. They show the format. On October 23, 2026, CISA listed a KEV entry made up of a CVE ID, a vendor and product name, and a short flaw description.

On October 26, 2026, CISA listed two PHP entries. CISA's alert covers both of those PHP entries. On October 27, 2026, CISA listed another pair of entries, the first of which was a separate vulnerability. The second entry that day was a Google Brotli flaw.

Each line therefore has three pieces: a CVE ID, a vendor and product name, and a short description of the flaw type. These alert pages carry no version numbers, no platform details and no configuration data. Anything finer than vendor, product and CVE has to come from somewhere else.

Why the CVE ID is the anchor

The CVE ID is the one element CISA requires. The alert pages state that a CVE ID is required for a catalog entry. An entry cannot reach the catalog without one.

CISA's binding directive for federal agencies is also written in terms of CVE IDs. CISA says BOD 26-04 is framed around CVE IDs. So the CVE ID is the key that ties a catalog entry to a remediation duty, and your own tracking should carry it as the common identifier.

The directive's scope has limits. CISA's alert says the directive is aimed at federal agencies and that other organizations are encouraged to act too. For a private organization, that is encouragement and not a requirement.

Where the product name stops being enough

A vendor and product name works as a search term only when your inventory records the product. The PHP alert shows where that assumption fails. CISA's first action item is to inventory PHP in your environment.

The next sentence in that alert gives the reason PHP may be present without being listed as its own product. Searching your inventory for "PHP" as a listed product can miss PHP that arrives inside something else. CISA does not say how to find those embedded copies. It states the problem and the inventory instruction, and stops there.

The same alert shows how much detail an exposure check needs. CISA's alert describes which PHP components the flaws affect. It also lists PHP-FPM, php-cgi, FrankenPHP and LiteSpeed as affected. The one-line KEV entry, "PHP Memory Corruption Vulnerability", does not carry any of this. The advisory does.

What the advisory adds that the entry omits

For PHP, CISA's longer alert supplies what the short KEV line leaves out. On fixed versions, the alert names the versions that contain the fixes. That gives you version targets to compare against what you find.

On unsupported versions, the alert gives its own guidance for PHP releases that no longer receive fixes.

On priority, the alert says which systems to handle first, with internet-facing systems prioritized. This lines up with the directive's focus on publicly exposed assets.

On detection, the alert gives guidance on what to monitor for. CISA also points to a detection rule.

The October 26, 2026 update to this alert added the KEV status. CISA's alert says the update added that KEV status. The PHP alert was therefore published and revised before the KEV listing. That means the advisory text was available before the catalog entry for these two CVEs.

The other three KEV additions we reviewed, Arista VeloCloud Orchestrator, Adobe Commerce and Magento, and Google Brotli, appear in the alert pages only as one-line entries. Those pages do not describe affected versions or fixes. For those, the alert pages give you only the vendor, the product and the CVE ID.

Where CPE strings fit

The documents we were given do not mention CPE strings. None of the four CISA pages uses the term, explains the format, or says whether CISA's KEV entries carry CPE data. We cannot tell you from these sources how a CPE string maps to an entry in your inventory, which tools produce or consume one, or how reliable the match is.

What the documents do establish is the gap a CPE string would be used to fill. The KEV alert lists a vendor, a product and a CVE ID. The inventory has to be searched with those. Where the product is embedded in other software, CISA says the match .

Any claim about CPE beyond that needs a source we have not been given. A reader who wants the CPE answer should look to the documentation for the vulnerability database or scanner they already use. This guide does not cover it.

The working sequence the documents support

Taking only what the four pages say, the sequence for a KEV addition looks like this:

• Record the CVE ID, vendor and product from the alert.
• Search your inventory for that product, and treat a miss with caution, since CISA warns the product may sit inside other software.
• Read the vendor or CISA advisory, where one exists, for affected components, fixed versions and unsupported versions.
• Prioritize internet-facing systems.
• Patch, or take systems offline if you cannot.
• Monitor for the activity CISA describes.

For federal civilian agencies, the directive adds a step. CISA says BOD 26-04 sets further expectations for federal civilian agencies. The documents do not spell out those expectations, so we do not either.

The documents leave one gap open. They say nothing on how to turn a vendor, product and CVE ID into a reliable asset match when the product is not listed in the inventory. They name the problem for PHP and tell teams to inventory it. They do not name a method.