CISA's notes field marks 77 of 1,748 KEV entries (4.4%) as involving an open source component, a third-party library or a protocol that different products share. Linux kernel entries lead. The phrase first appears on 2023 additions, so older entries are likely undercounted. The yearly count grows from 8 in 2023 to 28 in 2026.
Method
We downloaded the KEV JSON on 19 October 2026 (version 2026.10.16) and searched the notes field for the phrase "open-source", ignoring case. We then grouped matches by year added and by vendorProject and product. This depends on CISA's wording: an open source flaw whose note does not use the phrase is missed, and the phrase proves only that CISA flagged it, not that every user of the project is affected.
What the notes say
Two note variants account for most matches. One states that the flaw affects a common open source component, third-party library, proprietary implementation or protocol used by different products, and asks readers to check with specific vendors for patching status (40 entries). A second says the flaw could affect an open source component or library that different products use (20 entries). The remaining 17 use other wording.
The effect is a pointer to the supply chain: the product named in the entry may not be the only place the flaw lives.
The counts
| Year added | Entries with an open source note |
|---|---|
| 2023 | 8 |
| 2024 | 16 |
| 2025 | 25 |
| 2026 (to 16 October) | 28 |
The products named most often are the Linux kernel (18 entries) and a set of chipset entries (4). Others include Apache OFBiz (3), Langflow (2), GeoServer (2) and ScadaBR (2), plus single entries for BIND and Struts. Separately, the Linux kernel appears as a product in 31 entries over the life of the catalog, 8 of them in 2026.
Why this matters for dependency owners
A KEV entry for a library is different from one for a finished product. A product vendor ships a patch and you apply it. A library is embedded in other software, so the work is to find where you use it, in which versions, and whether the vulnerable code is reachable from your own code.
That is an inventory question. If you hold a list of components and versions for each application, you can match an entry to your estate in minutes. If you do not, the vendor advice to check with each vendor becomes a long email thread.
A short routine
- When an entry carries an open source note, search your software bills of materials for the component first.
- Check the version against the affected range in the advisory.
- Look at whether the vulnerable function is called. A component that is present but never reached is lower priority than one on a request path.
- Record the decision, including when the answer is "not affected", so the next review does not repeat the work.
Safeguard's SBOM and dependency scanning lists the components you run, and reachability analysis helps separate vulnerable code your application calls from code it does not. You can try a free scan at gold.safeguard.sh/scan.
Try it yourself
Click through it at your own pace, or open it full screen.
Open a project inventory and find a component by name and version, as you would after an open source note.
Quick check
Do the notes list every open source flaw in KEV?
No. They reflect CISA wording and first appear on 2023 additions in our data, so older entries often lack them.
Does an open source note mean I am affected?
No. It means the flaw is in a shared component. You still have to check whether you use it, which version, and whether the vulnerable code is reachable.
Sources
- CISA Known Exploited Vulnerabilities catalog, JSON read on 19 October 2026, catalog version 2026.10.16 (1,748 entries).
Last reviewed: 19 October 2026.
