SBOMs and KEV: finding Brotli and PHP, and what CISA's alerts require

What the documents cover and what they leave out

The question assumes CISA's alerts explain how a software bill of materials (SBOM) helps find affected systems. They do not. The alerts on Brotli and PHP talk about inventory, patching and monitoring, and none of them uses the term SBOM in its text.

The only SBOM reference in this document set is a headline. CISA's press release page for its new strategy lists a related article from July 29, 2026 titled "CISA and Partners Unveil Updated Software Bill of Materials Resource That Improves Transparency, Security and Risk-Informed Decision Making." The article itself is not in the documents, so this guide cannot say what that resource contains or how it works.

What the documents do give is CISA's own account of the problem an SBOM would address: components that are hard to see. The sections below stay with that.

The Brotli addition on October 27, 2026

CISA's alert dated October 27, 2026 says it added two vulnerabilities to the Known Exploited Vulnerabilities (KEV) Catalog. One of them is listed as "CVE-2026-111497 Google Brotli Unchecked Return Value Vulnerability." The other is in Adobe Commerce and Magento.

The alert gives the CVE ID, the vendor and product name, and the type of weakness. It does not say which products embed Brotli, which versions are affected, or what fixed version to move to. A security team reading it would have to work out where Brotli sits in its own estate. This is the shared-library situation the question describes.

CISA's stated reason for the generic warning is that "These types of vulnerabilities are a frequent attack vector for malicious cyber actors."

The PHP alert: the closest CISA comes to the question

CISA's PHP alert, last revised October 26, 2026, is more detailed. It says the "php2shell" vulnerabilities, CVE-2026-109618 and CVE-2026-109619, "allow for unauthenticated remote code execution in PHP." It also says the vulnerabilities affect all PHP installations serving web requests.

The alert's first action item is to identify and inventory systems. It reads: "Identify and inventory systems running any version of PHP across your organization." The next sentence explains why this is hard: "PHP is often a component of other software and prevalence may not be directly observable."

Those two sentences describe the gap. A team that checks only the servers it knows run PHP can miss PHP that ships inside other software. The alert does not name a tool or data source for closing that gap, and it does not mention SBOMs. Any link between an SBOM and this inventory step is the reader's, not CISA's.

CISA also says it added both PHP CVEs to the KEV Catalog on October 26, 2026. The fix it names is an update to PHP 8.5.12, 8.4.27, 8.3.36 or 8.2.35.

The response CISA asks for in the PHP alert

After the inventory step, the alert sets an order of work. Patching comes next, with internet-facing systems first.

For systems that cannot be updated, the alert is blunt. Organizations that cannot update immediately, or that run PHP 8.1 or earlier, should take PHP-based systems offline until they are patched or updated. The alert allows one partial measure in the meantime: "A web application firewall may provide some protection until systems are updated or patched."

The alert also asks for monitoring, specifically for "PHP worker processes launching shells or downloading tools." CISA points to its SIGMA detection rule for this. The rule is meant to help identify potentially suspicious activity in relevant log sources.

Finding every PHP instance is therefore the first step of a sequence, not the whole job. Patching, offline fallback and monitoring all depend on knowing where PHP runs.

What BOD 26-04 adds for federal agencies

Both KEV alerts, dated October 27 and October 28, 2026, repeat a paragraph about Binding Operational Directive (BOD) 26-04. CISA says the directive requires federal agencies "to prioritize rapid remediation of high-risk vulnerabilities."

The alerts add that the directive sets expectations for checking whether threat actors compromised a system before the patch was applied. For a shared component, that means patching is not the end point. The alerts treat a check for earlier compromise as part of the response, and that check also depends on knowing which systems ran the component.

The directive's scope is limited. CISA says it covers Federal Civilian Executive Branch agencies, but that it encourages all organizations to adopt risk-based vulnerability management.

The October 28, 2026 alert lists two further additions, one in Broadcom VMware ESX and one in the Linux kernel. It carries the same BOD 26-04 text and the same general guidance as the Brotli alert.

What a security team can take from these alerts

From these documents alone, the response to a KEV addition in a shared component has five parts, in CISA's order of emphasis:

• Identify every system that runs the component, including systems where it is embedded in other software.
• Patch, starting with internet-facing systems.
• Take systems offline if they cannot be patched.
• Monitor for suspicious activity.
• For federal agencies, check for compromise before the patch was applied.

CISA's alerts support the first item as a requirement, and they say plainly that embedded components are hard to observe. They do not say how to build or query an SBOM, which fields it needs, or whether a given SBOM would have listed Brotli or PHP. Teams that want that detail will need the SBOM resource named in CISA's July 29, 2026 press release, or their own vendor documentation. Neither is in this document set.