25 exploited vulnerabilities in Article 14's first 20 days: what they say about your SBOM

Between 11 and 30 September 2026, the first 20 days in which CRA Article 14 reporting applied, CISA added 25 CVEs from 18 vendors to its Known Exploited Vulnerabilities (KEV) catalogue. Only 3 of them, all in the Linux kernel, are published in OSV against an open-source package ecosystem that a dependency SBOM would match. The other 22 are vulnerabilities in vendors' own products: Cisco, Citrix, Check Point, JFrog, GitLab, WordPress, Apple and others.

What did CISA add to KEV in September 2026?

CISA added 25 CVEs from 18 vendors between 11 and 30 September 2026. Twenty-two were flaws in products the vendor itself ships, such as appliances, servers and phones, and three were Linux kernel flaws. Cisco and Linux had three entries each; Check Point, Citrix and JFrog two each.

"OSV ecosystem" in the table answers one question: is this CVE published in OSV against a package ecosystem, so that a component in an SBOM could match it? EPSS is the score from FIRST on 1 October 2026, the day the numbers were collected.

By our own grouping, not CISA's, eleven of the 22 non-kernel entries are network and security appliances (Cisco, Check Point, Citrix, F5, Arista, Zyxel, MikroTik). Nine are server or business software (JFrog, GitLab, WSO2, Microsoft, Adobe, WordPress, ConnectWise, Acronis). Two are phones and operating systems (Apple, Google).

Will CISA KEV entries match the dependencies in my SBOM?

On this sample, rarely. Only 3 of 25 additions could match a component in a dependency SBOM, and all three were Linux kernel flaws. Nothing was published against npm, PyPI, Maven, Go or crates.io. If you build a web application or a desktop tool on a language registry, this month's KEV additions would not have lit up your dependencies.

That finding cuts against how KEV monitoring is usually sold. The pitch is that you watch the catalogue and your SBOM tells you when something you ship is being exploited. That works when the exploited code is a component, as it was with Log4j. Most KEV entries are different. In this window, most entries were products exposed at the edge of a network or run as servers, such as gateways, email security appliances and admin consoles. The vulnerable code was the vendor's own.

Watching KEV against your SBOM is still worth doing: it is cheap, and it matters most in the month a popular library lands in the catalogue. But a quiet dependency check is not evidence that Article 14 will stay quiet for you. Your largest exposure is an exploitation report naming your own product. The monthly KEV digest tracks how often each kind turns up.

Why device makers are the ones KEV reaches through the SBOM

A manufacturer whose router, gateway, camera or controller runs embedded Linux ships the kernel as part of the product. If its firmware SBOM lists the kernel with an accurate version, the three kernel entries can match it.

That is not true of every Linux-based product. A container image does not contain a kernel; it uses the host's. A container SBOM therefore cannot match a kernel CVE, which is one of the reasons a container SBOM often matches nothing. The kernel lives in the SBOM only when you ship the operating system yourself.

For a device maker, a kernel KEV match starts an assessment, not a report:

1. Does the shipped kernel version fall within the affected range, after your backported patches?
2. Is the vulnerable subsystem compiled in and reachable in the product as shipped?
3. Do you have evidence of exploitation against your product or your users?
4. Which shipped versions, still within their support period, contain it?

Our alert tiering treats a KEV match as the most urgent kind of alert. Even so, a match only opens a triage record. It never starts a deadline.

Is every KEV entry an Article 14 event for its manufacturer?

Not automatically, but for the manufacturer of the listed product it plausibly is. Article 14(1) requires a manufacturer to notify any actively exploited vulnerability contained in its product with digital elements that it becomes aware of.Art. 14⁠(1)⁠ A KEV listing is public evidence of active exploitation. For the manufacturer of the listed product, KEV is not describing someone else's code. It describes theirs.

Whether a report is actually owed depends on facts this data cannot show:

• The product must be on the EU market. Article 14 applies to products with digital elements made available in the Union. A product sold only outside the EU is not caught.
• The listed versions must be ones the manufacturer placed on the market. Older products still within their support period count. The CRA has no legacy exemption.
• Awareness is a recorded decision. The 24-hour early warning and the 72-hour notification run from the moment the manufacturer becomes aware.Art. 14⁠(2)⁠ What becoming aware actually means covers why that moment is a decision someone records, not a feed timestamp.

We do not know, and do not suggest, whether any manufacturer named in the table filed an Article 14 report; that is not public. The pattern is the useful part. In this window, 22 of 25 entries were exploitation of a vendor's own product. If you are a software or device manufacturer, the KEV entry most likely to start your clocks is one that names you.

The practical consequence: read KEV, and the ENISA EUVD, for your own vendor and product names, not only for your components. If one names you, the early warning, the notification and, once a corrective or mitigating measure is available, a final report within 14 days may follow.Art. 14⁠(2)⁠⁠(c)⁠

Why EPSS is not a reportability signal

EPSS estimates how likely a vulnerability is to see exploitation activity in the next 30 days. Every vulnerability in this table is already confirmed as exploited. Their scores were still mostly low. Of the 24 with a score, 6 were at or above 0.10, and 7 were below 0.01. The median was about 0.021.

Examples from the table:

• Acronis Backup (CVE-2026-87886) scored 0.00233, the lowest in the set. That placed it around the 13th percentile of all scored CVEs, despite being in KEV.
• GitLab (0.91425) and Adobe Commerce (0.87507) scored highest, both above the 99th percentile.

This is not a criticism of EPSS. It is a model of the future, useful for ranking a backlog of unexploited CVEs. It does not record whether exploitation has already happened, which is the Article 14 question. A process that escalates only at an EPSS of 0.10 or more would have let 18 of these 24 confirmed-exploited vulnerabilities wait. Use KEV and EUVD to ask whether something has been exploited, and EPSS to decide what to look at next.

Method: how the numbers were counted

Every figure here comes from one script, using public feeds only and no customer data.

1. KEV additions. The script downloads the CISA KEV catalogue JSON feed and keeps entries whose dateAdded falls between 11 and 30 September 2026 inclusive. The catalogue version used was 2026.09.30, released 30 September 2026 at 16:59 UTC, with 1,730 entries in total.
2. Vendors. Counted from the catalogue's vendorProject field: 18 distinct values.
3. OSV ecosystem. For each CVE, the script queries the OSV API for the CVE record and follows its aliases and related IDs into ecosystem advisories (GitHub, PyPI, Go, RustSec, Debian, Ubuntu, AlmaLinux, Red Hat, SUSE and Alpine). A CVE counts as "published against an open-source ecosystem" if any of those records lists an affected package in any ecosystem other than a bare Git repository.
4. EPSS. Scores and percentiles come from the FIRST EPSS API, queried on 1 October 2026. One CVE, added on 30 September, had no score yet. The median is the lower of the two middle values of the 24 scores: 0.02101, with the upper one at 0.02226.
5. Ransomware. KEV's knownRansomwareCampaignUse read "Unknown" for all 25.

To reproduce, run from the repository root:

node scripts/content/kev-stats.mjs 2026-09-11 2026-09-30

The output used here is content/data/kev-stats-2026-09-11-to-2026-09-30.json, and the same data feeds our CRA statistics page.

Limitations

• OSV coverage is not the same as "open source". WordPress core and GitLab Community Edition are open-source products, but in this run neither was published in OSV against a package ecosystem. A vendor who bundles one inside an appliance would still carry it as a component that OSV would not match.
• "Yes" is coarse. It means a matching package exists in OSV, not that your SBOM names it with the identifier and version that would match.
• EPSS moves daily. The scores are as of 1 October 2026 and will have changed by the time you read this.
• KEV is a US catalogue. ENISA keeps a separate European list, and the two overlap heavily but not entirely. The EUVD post explains the differences and why the reporting form asks for the EUVD identifier.
• Twenty days is a short window. Twenty-five entries is not a trend. A month in which a widely used library lands in KEV would look very different, and the script runs for any window.

What to do this week

1. Search KEV and EUVD for your own name. Watch for your company and product names, not only your components.
2. If you ship firmware, check the kernel line in your SBOM. Record the kernel version you actually ship and the fixes you have backported, so a kernel match can be assessed in hours.
3. Run your SBOM through the free KEV check. It tells you in a minute whether anything you ship is on the catalogue now. Nothing is stored.
4. Remove any EPSS gate from your escalation rule. A confirmed exploitation should reach a person whatever its EPSS score. Article 14 in plain language sets out what happens after that person decides.