CISA added 34 flaws to the exploited catalogue in September, and 26 came with a three day deadline
The three day remediation deadline was meant to be the exception. In September 2026 it applied to 26 of 34 additions, and on the 22nd four remote access products were added together, all due on the 25th.
By Parminder Kumar Sharma · · 9 min read
Twenty six out of thirty four
I pulled the CISA Known Exploited Vulnerabilities catalogue this morning: version 2026.09.23, released at 12:51 UTC yesterday, 1,721 entries.
In the first 23 days of September, CISA added 34 vulnerabilities. Of those, 26 carry a three day remediation deadline and 8 carry fourteen days.
That is 76 per cent on a seventy two hour clock. The short deadline is no longer the exception applied to the worst cases. It is what a KEV entry looks like now.
And on 22 September, four entries were added on the same day, all due on 25 September: Arista VeloCloud Orchestrator, F5 BIG-IP APM, and two covering multiple Check Point products.
Every one of those four is a remote access product. They are the boxes an organisation puts in front of everything else.
Say what that does not establish, because this one invites overreach.
It does not establish that CISA is wrong. A three day deadline on a device that terminates remote access, when exploitation is already confirmed, is defensible. The alternative is a deadline nobody believes.
It does not establish that attacks are increasing. The catalogue counts additions, which is a measure of CISA's intake and publication process as much as of the threat. A busier month at CISA and a busier month for attackers are not the same thing, and the file cannot tell them apart.
It does not establish that anybody missed the deadline. Compliance data is not published.
And it does not apply to you, if you are reading this in the United Kingdom. The required action on every one of these entries cites a Binding Operational Directive, which is an instruction to United States federal civilian agencies. You have no obligation here at all. What you have is a free, well maintained list of things somebody has confirmed are being exploited, which is considerably more useful than an obligation.
Four edge devices, one afternoon, seventy two hours
The 22 September batch is worth looking at as a batch rather than as four separate advisories, because that is how it arrives at an organisation.
All four required actions carry the same text: apply mitigations in accordance with vendor instructions, ensuring compliance with the relevant binding directive. All four were due on 25 September.
The four entries added to the CISA KEV catalogue on 22 September 2026, from catalogue version 2026.09.23. Vulnerability names are CISA's own.
| CVE | Vendor and product | Weakness named by CISA | Due |
|---|---|---|---|
| CVE-2026-93952 | Arista VeloCloud Orchestrator | Improper input validation | 25 September |
| CVE-2026-94127 | F5 BIG-IP APM | Heap based buffer overflow | 25 September |
| CVE-2026-93616 | Check Point, multiple products | Path traversal | 25 September |
| CVE-2026-85102 | Check Point, multiple products | Improper certificate validation | 25 September |
Now consider what complying with that actually requires.
These are not workstations that take a patch overnight from a management server. An SD-WAN orchestrator, an access policy manager and a pair of security gateways are devices whose upgrade needs a maintenance window, a change approval, a rollback plan, and somebody awake at the other end of a remote site if it does not come back. In many organisations they are the devices the change advisory board looks at most carefully, precisely because breaking one disconnects everybody.
Three days, for four of them, at once, spanning a weekend.
The deadline is not adjusted for any of that. It does not know whether the fix is a package update or a firmware replacement, whether it needs downtime, whether the vendor has shipped a fixed build for your particular model, or whether you have four of these devices or four hundred. It is a fixed number attached to an exploitation fact.
That is a reasonable design for a compliance instrument, which has to be uniform to be enforceable. It is a poor design for a prioritisation signal, which is what almost everybody outside the United States federal government actually uses it as.
September is the busiest month of the year
Counted by month, 2026 has been fairly steady and then turned upward.
The catalogue has taken 237 additions in 2026 to 23 September, across 266 days, which is a mean of 0.89 a day. September alone has taken 34 in 23 days, which is 1.48 a day, about 66 per cent above the yearly mean and about half as much again as August. If the September rate held to the end of the month, the total would land near 44.
Be careful with that upward turn. A rise in additions can mean more exploitation, or better reporting into CISA, or a policy decision to catalogue more aggressively, or simply that several vendors happened to confirm exploitation in the same fortnight. The file records the decision to add, not the event that prompted it.
What the file does support is a statement about workload. Whatever the cause, an organisation that treats every KEV addition as an action item took on 34 of them this month, 26 of which claimed to need finishing inside three days.
That is roughly one emergency change every day and a half, sustained, on top of everything else.
What the catalogue does not contain
This week produced several separate stories describing flaws as under active exploitation. Two of them are worth checking against the catalogue, because the phrase turns out to cover very different situations.
JetBrains TeamCity. The catalogue's most recent TeamCity entry is CVE-2026-63077, added on 5 August 2026. That is 50 days ago. Whatever is newsworthy about TeamCity this week, a fresh catalogue entry is not part of it.
Roundcube. The catalogue's most recent Roundcube entries were added on 20 February 2026, 216 days ago. As of version 2026.09.23 there is no 2026 Roundcube entry more recent than that.
I should be straight about the limit on this section. I verified both statements against the catalogue file itself, which is a primary source and which I fetched. I was not able to fetch the vendor advisories or the news reports behind this week's coverage, so I cannot confirm which specific flaw each of those reports concerns. What is stated here is what the catalogue contains, and nothing more.
The general point survives that limit, and it is the useful one. "Actively exploited" is a single phrase doing several different jobs at once: a new catalogue entry with a three day clock, an old catalogue entry that a new class of attacker has started using, and a flaw with confirmed exploitation that is not in the catalogue at all. Those three demand different responses, and a prioritisation process keyed on the phrase cannot tell them apart.
Three states a vulnerability can be in while the same phrase is used about it. The right hand column is what a team keying on the phrase alone will get wrong.
| State | What it means for you | The failure if you do not distinguish |
|---|---|---|
| Newly added to the catalogue | Confirmed exploitation, and a deadline attached | You treat it as routine and miss the clock |
| In the catalogue for weeks, now used by a new actor | You should already have fixed it. The news is the actor, not the flaw | You re-run an emergency change for something you closed in August |
| Exploited, but not in the catalogue | No deadline, no entry, and your process may never see it | You never act, because nothing in your tooling fires |
How to use the catalogue if you are not a US federal agency
Take this with you
Treating KEV as a signal rather than an obligation
- Filter the catalogue against your own asset inventory before anything else. Of 1,721 entries, the number that touch your estate is small, and that intersection is the only list worth arguing about.
- Separate the deadline from the risk. The date is a federal compliance artefact. Use it as evidence that exploitation is confirmed, and set your own timescale from your own exposure.
- Give edge and remote access devices their own track, with a standing maintenance window and a pre-approved rollback. Four of them landed together this month and that will happen again.
- Record the date you first saw each entry, not only the date you closed it. Your own lag is the number you can actually manage.
- Do not key your prioritisation on the phrase actively exploited. Key it on whether the vulnerable thing is reachable from where the attacker is.
- Check the catalogue for things you have already patched before treating a news story as an emergency. An old entry resurfacing is a reporting event, not a change request.
- Watch for confirmed exploitation that is not in the catalogue at all, because nothing in your tooling will raise it for you. The catalogue is a floor, not a ceiling.
The catalogue is one of the genuinely good things in public sector security. It is free, it is maintained, it is specific, and it makes a falsifiable claim about each entry.
The three day deadline is the part that has quietly drifted. It was introduced as the urgent tier and it is now the default tier, applied to 26 of 34 additions in a month, including to four devices that most organisations cannot safely change inside a week.
So the question is not whether you are meeting it, because you are almost certainly not obliged to.
It is this. When your team sees the next KEV entry with three days on it, do they open a change, or do they already know that the date is not real? Because whichever answer is true is now the actual policy, and nobody wrote it down.
