CISA catalogued three exploited flaws this evening that nobody has reported. Two of them cannot be found by vendor name.

CISA added seven entries to the Known Exploited Vulnerabilities catalogue at 16:54 UTC today. Four of them are stories you have already read: two SonicWall identifiers, one from JFrog, one from Sangoma.

The other three have had no coverage at all. Kestra, LiteLLM and Starlette.

They deserve some, because two of the three cannot be found the way a KEV entry expects you to look for them. A catalogue entry names a vendor and a product, which is how procurement thinks about software. It is not how software is assembled.

Three in the catalogue, and how you would find them

The one that is not in anybody's inventory

Starlette is not a product. It is the ASGI toolkit that FastAPI is built on, and it arrives in an estate because somebody chose FastAPI, or chose something that chose FastAPI.

CVE-2026-48710 is a Host header validation failure, and the mechanism is worth understanding because the defence people assume they have is the thing that fails. In Starlette before 1.0.1, the HTTP Host header was not validated before being used to reconstruct request.url. Routing uses the raw HTTP path, but request.url is rebuilt from the Host header, so a malformed header can make request.url.path differ from the path that was actually requested.

The consequence, in the advisory's own terms: middleware and endpoints that apply security restrictions based on request.url rather than on the raw scope path can be bypassed.

That is a specific and common pattern. Anyone who has written a path-prefix guard in middleware, an admin-route check, or a rate limiter keyed on the URL has probably reached for request.url. It is the obvious attribute. It is also the one that can be made to lie.

Fixed in 1.0.1. And the identifier is the one nobody will search for, because nothing in an asset register says Starlette.

The one your AI team stood up without telling anybody

CVE-2026-59822 is in LiteLLM, an AI gateway that proxies calls to model providers. Before 1.84.0, its MCP Streamable HTTP endpoint accepted a fabricated Authorization header, which triggered an OAuth2 passthrough fallback that replaced failed LiteLLM key validation with an empty UserAPIKeyAuth() object. Requests then reached MCP tooling without a valid key.

Read that mechanism again, because it is a familiar shape in a new place. A failed authentication check falls back to a permissive default rather than a denial. That is the oldest authentication bug there is, and it is now sitting in front of the tool-calling surface of an AI gateway.

LiteLLM is the middle case for inventory. It is a named product, so it can be found by name, but it is frequently installed by an AI or data team as a proxy rather than procured, which means it may be in no register at all. If you want to know whether you run it, ask the people building with models, not the CMDB.

The one with three days

CVE-2026-49869 in Kestra is the only one of the three with a 5 September deadline, and it carries CVSS 10.0.

The flaw is a single line of logic. AuthenticationFilter used request.getPath().endsWith("/configs") to exempt the public configuration endpoint from Basic Auth. Because that is a suffix match and not an exact path match, any API path whose last segment is configs bypasses authentication entirely. Kestra ships with script plugins enabled, so an unauthenticated attacker can create and execute workflows.

Affected: below 1.0.45, and from 1.1.0 up to 1.3.21.

endsWith where equals was meant is the kind of mistake that survives review precisely because it reads correctly in English.

The KEV title is a lossy summary, and for two of these it misdirects

Here is something worth knowing about how these entries are named, because triaging from the catalogue title alone will send you to the wrong place.

CISA titles Starlette's entry "HTTP Request/Response Smuggling Vulnerability". That is not an invention: CWE-444 is in the CVE record itself, assigned by GitHub as the numbering authority. But the same record's own title reads "missing Host header validation that poisons request.url.path, bypassing path-based security checks". The record disagrees with itself, and the catalogue inherited the less useful half. A team that reads "request smuggling" will go looking at their reverse proxy and their load balancer, which is not where this lives.

Kestra is the same shape. CISA titles it "OS Command Injection", taking CWE-78, which is the first of four CWEs on the record. The CNA's own title calls it "Unauthenticated Remote Code Execution via Authentication Bypass". Command execution is the consequence; the authentication bypass is the flaw. Search your code for command injection and you will find nothing.

LiteLLM is titled "Improper Authentication", which matches both its CWE and its mechanism. One of three.

What each record actually says, against what the catalogue calls it

Identifier	KEV calls it	The record’s own title	NVD
CVE-2026-48710, Starlette	HTTP Request/Response Smuggling	Missing Host header validation that poisons request.url.path	Primary 6.5, the lowest of the three
CVE-2026-49869, Kestra	OS Command Injection	Unauthenticated RCE via authentication bypass	No NVD primary. The 10.0 is GitHub’s
CVE-2026-59822, LiteLLM	Improper Authentication	MCP authentication bypass via OAuth2 passthrough fallback	Primary 8.2, against GitHub’s 8.8

Note the severity column against the exposure. Starlette scores 6.5, the lowest of the three, and has by far the widest blast radius, because it sits underneath a framework rather than in front of a user. Severity and exposure are measuring different things and only one of them is on the entry.

None of this is new code

The gap between each CVE record's publication and its appearance in the catalogue: 99 days for Starlette, 68 for Kestra, 56 for LiteLLM.

All three were fixed upstream long before today. Nothing about the code changed this afternoon. What changed is that CISA now asserts they are being exploited, which is the same lesson as the piece published here this morning arriving from the other direction: absence from the catalogue was an absence of evidence, and this is what it looks like when the evidence turns up.

One caveat worth stating plainly. CISA is the only public source asserting exploitation for all three. No vendor telemetry, no research write-up and no accompanying advisory came with them. That is normal for KEV and it is not a reason to discount it, but it does mean there is nothing further to read, and no host counts or victim details exist to be quoted.

The position

The catalogue is not at fault, and it is worth saying that clearly because the criticism here is structural rather than editorial. A public list has to name things in one short line, and vendor-and-product is the only naming scheme that works for most of what goes into one.

The problem is that a growing share of what actually runs in an estate did not arrive through purchasing. It arrived as a transitive dependency of something else, or was stood up in an afternoon by a team that needed a proxy. No naming scheme built around procurement will ever reach either.

Which makes the honest reading of today's catalogue update this: for one of these three, the entry tells you a vulnerability is being exploited and gives you no way to find out whether you have it. The answer is in your lockfiles, and it always was.