Half of what CISA now flags as exploited arrives through your dependency tree

3 September 2026

The Known Exploited Vulnerabilities catalogue used to be a list of other people's problems: firewalls, VPN concentrators, mail gateways. If you did not sell a box, it was not about you. That stopped being true, and the shift is measurable.

We pulled the KEV catalogue published on 2 September 2026 — 1,694 entries — and split each one by how the software reaches a victim. Some of it is bought and installed: a Fortinet appliance, a SonicWall gateway, a Windows component. The rest arrives silently, as a transitive dependency, in a build nobody reviewed line by line.

Year added	Total	Bought & installed	Arrived as a dependency	Share
2021	311	218	93	30%
2022	555	420	135	24%
2023	187	118	69	37%
2024	186	121	65	35%
2025	245	139	106	43%
2026	210	113	97	46%

The share has roughly doubled since 2022. The classification is a heuristic — vendor and product names matched against a list of appliance and platform vendors — so treat the exact percentages as approximate and the direction as solid. The feed is public; the split is reproducible in an afternoon.

What the recent entries look like

The four most recent library entries at the time of writing, all added on 2 September 2026:

Added	Project	CVE
2026-09-02	Starlette	CVE-2026-48710
2026-09-02	LiteLLM	CVE-2026-59822
2026-09-02	Kestra OSS	CVE-2026-49869
2026-09-02	JFrog Artifactory	CVE-2026-82329

Starlette is the one to look at. It is not a product anybody buys — it is what FastAPI is built on, which means it sits inside a very large number of Python services whose authors have never typed its name. Nobody decided to run Starlette. They decided to run FastAPI, and Starlette came along.

That is the whole shift in one line. The exploited thing is no longer something you chose. It is something you inherited.

Why this lands on the Cyber Resilience Act

Since 11 September 2026, a manufacturer placing a product with digital elements on the EU market has 24 hours from becoming aware that a vulnerability in that product is actively exploited to send an early warning to ENISA and their national CSIRT. Not 24 hours to fix it. 24 hours to report it.

Read those two facts together and the consequence is uncomfortable. The obligation is triggered by exploitation, exploitation is increasingly found in ordinary libraries, and ordinary libraries are in everyone's build. The population of companies that can have a clock start inside their product is expanding, and most of them have not noticed because they do not think of themselves as security vendors.

A company that ships a web service, uses FastAPI, and has never sold an appliance in its life can now be four dependency hops from a CVE that CISA says is being exploited in the wild. In 2022 that was unlikely. In 2026 it is roughly a coin flip on any given KEV update.

The number that actually matters is not 1,694

There are millions of known CVEs. There are 1,694 entries in KEV. And of the 2026 additions, 21% are linked to known ransomware campaigns.

That ratio is the entire point of Article 14, and it is what most vulnerability tooling blurs. A scanner that reports "312 components, 47 vulnerabilities" has told you almost nothing about your reporting obligation, because the regulation does not turn on whether a vulnerability exists. It turns on whether someone is using it.

A published proof of concept, a researcher demonstrating exploitability, or a disclosed-but-unexploited CVE does not, on its own, start the clock. Evidence of exploitation does.

Which means the useful question is not "how many vulnerabilities do I have" but "how many of mine are on the list of things being exploited right now" — a much smaller number, and a much more actionable one.

What to do with this

Know what is in your build. Not the direct dependencies — the transitive ones, where Starlette lives. You need an SBOM, and syft or cdxgen will produce one free.
Check it against exploitation, not against severity. CVSS tells you how bad a vulnerability would be. KEV tells you whether it is happening. Only the second one is what Article 14 asks about.
Do it continuously, not once. KEV gained 87 entries between June and September 2026. A scan from last quarter says nothing about today, and the 24 hours run from awareness — which the regulator may reasonably date from when you could have known.

None of that tells you whether the vulnerable code path is reachable in your product. That judgement stays with the people who wrote it, and no tool should pretend otherwise. But knowing which four of your three hundred components are on the exploited list is the difference between a decision and a search.

Flagrante reads an SBOM and tells you which components carry a vulnerability CISA says is being exploited — the ones that start an Article 14 clock, separated from the thousands that do not.

pip install flagrante then syft dir:. -o cyclonedx-json | flagrante

Or drop an SBOM in the browser. It is never stored, anywhere.