28 exploited vulnerabilities in thirteen days: KEV signal

Between September 8 and 24, 2026, CISA added 28 vulnerabilities to its Known Exploited Vulnerabilities (KEV) catalog, by our count of the catalog's JSON file, current version (2026.09.24). Thirteen working days, 28 CVEs, almost all of them on devices that sit at the edge of the network or of identity. For those assets, a monthly patch cycle no longer holds.

What the sources say

The KEV catalog. CISA's JSON file gives, for each entry, the date added and the due date. From September 8 to 24, 2026, the sequence reads like an inventory of the perimeter:

Windows, Chromium V8, N-able, JFrog, GitLab, Cisco Secure Email Gateway and Google Pixel make up the rest of the 28. On the due date field, 23 entries give three days after the addition, the other five (two Windows, Chromium V8, two JFrog) fourteen days. The catalog page ties every required action to directive BOD 26-04 and makes each organization responsible for evaluating the internet exposure of its assets. CISA's alert of September 22, 2026, which adds F5, Check Point and Arista, recalls that BOD 26-04 requires federal agencies to prioritize remediation of the CVEs listed in the catalog.

The Canadian Centre for Cyber Security published four alerts in the window: AL26-020 on MikroTik RouterOS (September 10), AL26-021 on Cisco ISE (September 17), AL26-022 on F5 BIG-IP APM (September 22) and AL26-023 on Microsoft SharePoint Server, CVE-2026-65660 (September 24). The last one confirms active exploitation and recalls that SharePoint Server 2016 and 2019 have been end of life since July 15, 2026. On the European side, CERT-EU advisory 2026-013 of September 22 rates the F5 flaw critical (CVSS 9.8), with exploitation confirmed by the vendor.

ENISA published its Threat Landscape on September 22, 2026, covering the year 2025. Two figures: among unauthorized access incidents where an intrusion vector could be identified (5% of cases), 60% leveraged a vulnerability; and 2025 saw the publication of more than 48,000 CVEs, a 22% increase over the previous year.

Why it matters

Three observations.

First, the target. NetScaler, Fortinet, ISE, BIG-IP APM, Check Point, ScreenConnect: VPN gateways, access policy servers, administration consoles. They see credentials go by, they are exposed by design and they host no detection agent. A compromise there raises no alert: it grants an access that looks legitimate.

Second, the pace. Twenty-eight entries in thirteen working days, more than two a day, with a three-day due date for most of them. An organization that patches in monthly batches structurally arrives after the deadline CISA sets for its own agencies and, worse, after the attackers, since a catalog entry attests that exploitation has already started.

Third, the triage. CVSS measures what an attacker gets if the attempt succeeds, not whether anyone is trying; the KEV catalog answers the second question. With more than 48,000 CVEs published in 2025 according to ENISA, nobody fixes everything: confirmed exploitation is the first sorting criterion, asset exposure the second.

For the auditor, this translates into expected evidence: ISO 27001:2022, control A.8.8, wants technical vulnerabilities known and handled in time; NIS 2, article 21(2)(e), requires policies for vulnerability handling and disclosure; CIS v8 control 7 covers continuous vulnerability management. None of them says "three days", but all of them ask for a defined, justified and demonstrated timeframe.

What we think at Sentrix

This September is the most concrete argument we have seen for moving to continuous exposure management. In order:

1. Keep the inventory of exposed assets separately. Gateways, VPNs, administration consoles, federation servers, portals, with version and owner. When a KEV entry lands, "are we affected?" must be answered in minutes.
2. Use the KEV catalog as a trigger, not as weekly reading. The JSON feed is public and dated; compare it with the inventory every day. CVSS then orders what remains.
3. Adopt the three-day yardstick for an exposed asset listed in the catalog, and measure the gap. A missed and documented deadline is better than no deadline.
4. Treat end of life as a permanent vulnerability. A SharePoint 2016 or 2019 exposed after July 15, 2026 has no patch coming: exit date in the risk register, isolation in the meantime.
5. Collect the evidence once. Catalog entry date, detection date in the inventory, remediation date and signed exception form a single record, later presented under A.8.8, article 21(2)(e) or control 7 without rebuilding it.

That is the job of our CTEM continuous exposure module; our page on vulnerability and patch management describes the approach. Our articles on prioritizing with the KEV catalog and EPSS and on the five stages of CTEM detail the method.

The next step

Take the 28 CVEs of September and, for each one, write a line: affected or not, remediation date, gap against three days. If a line stays empty for lack of inventory, start there. Our watch tracks the next entries; to run the exercise with us, contact us.