Four KEV entries, one 61 day gap: Check Point's management server was attacked in July, fixed in September

Sixty-one days, then three

Check Point says it observed a small number of attacks against CVE-2026-93616 on 23 July 2026. The advisory describing that vulnerability, and the fix for it, was published on 22 September 2026. Count the days: 8 remaining in July, 31 in August, 22 in September. Sixty one days. On the same day the advisory appeared, CISA added the CVE to the Known Exploited Vulnerabilities catalogue with a remediation due date of 25 September, three days later.

So the public record now contains a 61 day interval in which a pre-authentication path traversal flaw in a Check Point management server was being exploited and no fix existed, followed by a 3 day interval in which every federal civilian agency is required to close it and then prove the box was not already owned.

What that arithmetic does not establish is more important than what it does.

It does not establish that anyone was compromised during those 61 days. Check Point's own wording is that it is aware of "a handful of customers who have been attacked", which is not the same as breached. It does not establish that the attacks continued across the whole period; the only date given is 23 July. It does not establish when Check Point learned of the flaw, only when it says attacks were seen and when it published. And it does not establish that the affected management interfaces were reachable from the internet, because none of the four advisories says so.

What the four records actually say

All four entries were added on 22 September 2026 and all four carry a due date of 25 September 2026. All four carry the catalogue's forensic triage flag. All four record ransomware campaign use as "Unknown". Every CVSS score below was assigned by the vendor acting as its own CVE numbering authority, not by NIST: in the NVD records each metric is typed as secondary and sourced from cve@checkpoint.com, psirt@arista.com or f5sirt@f5.com.

The four additions of 22 September 2026, from the CISA KEV JSON feed and the NVD records for each CVE

CVE and weakness	Component the advisory names	Exploitation the record states
CVE-2026-93616, CWE-22, CVSS 9.8	Check Point Security Management Server, Multi-Domain Management Server, Log Server, Multi-Domain Log Server, SmartEvent	Attacks observed 23 July 2026, before any fix existed
CVE-2026-85102, CWE-295, CVSS 9.8	Check Point Security Gateway and Spark Firewall, site to site or remote access VPN	No exploitation known at disclosure on 9 September; attempts from 12 September, against Spark
CVE-2026-93952, CWE-20, CVSS 10.0 (v3.1) and 9.5 (v4.0)	Arista VeloCloud Orchestrator, on premises only	Discovered externally and known to be actively exploited; no date given
CVE-2026-94127, CWE-122, CVSS 9.8 (v3.1) and 9.3 (v4.0)	F5 BIG-IP APM virtual server configured as an OAuth authorisation server	F5 states it has learned the flaw has been exploited; no date given

CISA's own supplementary analysis in the NVD records, published under the CISA-ADP source identifier rather than by any vendor, gives all four the same decision values: exploitation active, automatable yes, technical impact total. That triple is what drives the deadline, and it is the reason the four look interchangeable in a headline when they are not.

The two Check Point entries are two different boxes

CVE-2026-93616 is the management story. Check Point's SecureKnowledge article sk1000171 describes a directory traversal and file upload flaw in the Check Point management web service that lets an unauthenticated attacker upload and execute an arbitrary script and load an arbitrary Java class. The affected list is Security Management Server, Multi-Domain Security Management Server, Log Server, Multi-Domain Log Server and SmartEvent. The explicitly unaffected list is as informative: Check Point firewall appliances, Spark firewalls, and Smart-1 Cloud, where Check Point says the fix is already applied.

The mitigation Check Point offers is the one that gives away the exposure model. It asks customers to place management servers behind a gateway and to ensure that access to TCP/19009 is possible only from trusted addresses. A vendor does not write that sentence for a port nobody can reach.

CVE-2026-85102 is not that. It is improper validation of certificate data during VPN negotiation on the Security Gateway and on the Spark firewall, reachable by an unauthenticated attacker, leading to code execution on the gateway. For site to site VPN it affects gateways that use or allow certificate based authentication; communities authenticating only with a pre-shared key are not vulnerable. R82.20 is listed as not affected.

The observed exploitation is narrower still. Check Point disclosed and fixed the flaw on 9 September 2026 and says it had no evidence of exploitation at that point. The wave it describes began on 12 September, three days later, and the targets it names are Spark customers: the small and branch office appliance, not the data centre gateway. The certificate subjects it published as indicators, all variations on a common name of vpn, are crude. Check Point warns the list is not exhaustive.

The take that fixed one flaw is the top of the vulnerable range for the other

Read the two Check Point articles side by side and a practical trap appears. sk1000117 says the fix for CVE-2026-85102 arrives in Jumbo Hotfix Accumulator take 44 for R82.10, take 126 for R82, take 166 for R81.20 and take 190 for R81.10. sk1000171 lists the versions affected by CVE-2026-93616 as take 44 or lower for R82.10, take 126 or lower for R82, take 166 or lower for R81.20 and take 190 or lower for R81.10.

In every one of the four supported trains, the exact take that closes the September gateway flaw sits at the top of the range that is still open to the September management flaw. An administrator who moved quickly on 9 September, installed the accumulator, and marked the job done is, by the vendor's own version tables, on the most exposed patched build available.

Jumbo Hotfix Accumulator takes, from Check Point sk1000117 and sk1000171. The overlap is computed here by comparing the two tables.

Train	Fixes CVE-2026-85102 from take	Still exposed to CVE-2026-93616 up to and including take
R82.10	44	44
R82	126	126
R81.20	166	166
R81.10 (end of support)	190	190

The fix for CVE-2026-93616 begins one take later for R82.10 and R82, at takes 45 and 127, two takes later for R81.10, at 192, and four takes later for R81.20, at 170. R82.20 needs a separate security hotfix. Note also that the two flaws do not share a remediation mechanism: CVE-2026-85102 can be closed by Check Point LivePatch take 26, while sk1000171 states plainly that LivePatch take 28 or 29 does not address CVE-2026-93616 and that, because of the nature of the fix, no LivePatch will be available for it at all.

Where the four sit relative to the estate

F5: a data plane bug on the access proxy, and a mitigation you have to ask for

F5's article K000162605 was published on 22 September 2026 and updated on 23 September. It is narrow in a way that matters for triage. CVE-2026-94127 is a heap based buffer overflow that requires a BIG-IP APM access policy and an OAuth profile on the same virtual server, and it is present only where APM is configured as an OAuth authorisation server. Deployments using APM strictly as an OAuth client or resource server, with no authorisation server profile, are stated as not affected. Every other BIG-IP module, BIG-IQ, F5OS, NGINX, F5 Distributed Cloud and F5 AI Gateway are listed as not vulnerable.

The affected versions are BIG-IP APM 21.1.0, 17.5.0 to 17.5.1 and 17.1.0 to 17.1.3. The fixes are engineering hotfix ISOs rather than ordinary point releases, which is itself a signal about the timescale F5 was working to. F5 also notes that versions past end of technical support were not evaluated, so absence from the vulnerable list is not a statement of safety for an old box.

Two details deserve attention from anyone who thinks a hardened deployment mode is a boundary. F5 states that the BIG-IP system in Appliance mode is also vulnerable. And the only mitigation offered short of the hotfix is an iRule that customers must obtain by contacting F5 Support, so it cannot be applied from the advisory alone. CISA's KEV note for this CVE is the only one of the four with extra text, and it is precisely about that friction: apply the vendor provided iRule as a temporary mitigation to allow for proactive forensic triage, then install the final patch as soon as possible.

F5 says the issue was discovered internally. It confirms exploitation has happened without saying when, by whom, against how many, or whether it preceded the fix.

F5's indicators are the most operationally honest set of the four, because they are behavioural rather than a list of addresses that will be stale by the weekend. The pattern it describes is repeated OAuth userinfo failures in /var/log/apm, ten or more in a single log and especially from a single source address, followed by suspicious commands, followed shortly by a traffic management microkernel core dump caused by a SIGABRT. F5 is explicit that no single element confirms anything; it is the combination and the frequency that should send a human to look.

tmctl global_oauth_stat -s total_requests,total_userinfo_requests,total_failed

Arista VeloCloud Orchestrator: the third management plane

CVE-2026-93952 in the on premises VeloCloud Orchestrator was covered on this site when Arista published advisory 0183 on 22 September. Its arrival in the KEV catalogue the same day changes the deadline, not the facts. Arista scores it 10.0 under CVSS 3.1 and 9.5 under CVSS 4.0, describes it as discovered externally and known to be actively exploited, and says a remote attacker may reach privileged internal functionality and affect the orchestrator host itself.

Two points carry over into this story. Hosted and Dedicated instances were impacted and, Arista says, have already been patched, which leaves the on premises operator last in the queue for a flaw the vendor already fixed for its own tenants. The same pattern appears at Check Point, where Smart-1 Cloud is listed as not affected because the fix is already applied. Managed instances of a management plane get patched by the people who run them; yours gets patched by you.

Arista is also the only one of the three vendors to publish file names, a file hash and attacker addresses, while stating that there is no single definitive indicator of compromise for the issue. That combination, concrete artefacts plus an explicit warning not to treat them as a clean bill of health, is the standard the other two advisories should be read against.

The three day clock is now the normal setting, not the alarm

A three day remediation deadline reads as extraordinary. In September 2026 it was not. Counting every entry added to the catalogue between 1 and 23 September, there are 34, and 26 of them carry a window of exactly three days between the date added and the due date. The other eight carry fourteen days. Every one of the 25 entries flagged for forensic triage got three days; only one three day entry lacked the flag.

The mechanism behind this is Binding Operational Directive 26-04, issued on 10 June 2026, which replaced the old flat KEV deadline with a table driven by asset exposure, catalogue status, whether exploitation is automatable and whether the technical impact is total control. A publicly exposed asset with total impact gets three days plus a forensic triage requirement, meaning the agency must not only remediate but assess whether the system was already compromised. The four entries of 22 September all sit in that top box because CISA's own analysis marks them active, automatable and total.

Remediation windows for the 34 KEV entries added between 1 and 23 September 2026, computed from the dateAdded and dueDate fields in the KEV JSON feed

Window between dateAdded and dueDate	Entries	Carrying the forensic triage flag
3 days	26	25
14 days	8	0

The practical reading for a UK organisation, which is bound by none of this, is that the flag is a free severity signal. The directive's own logic says the flagged items are the ones CISA believes an attacker can exploit at scale against an exposed asset for total control. Treating the forensic triage flag as a hunting trigger, rather than the due date as a patching trigger, extracts the useful part of an American compliance instrument without pretending to be subject to it.

One honest caveat: the fourteen day window is not one of the intervals in the directive's table, which uses three, six, fifteen and thirty days. The inference that the fourteen day entries are simply carrying the catalogue's older default rather than a directive category is mine, not CISA's.

Three comforting labels that are not controls

"Known ransomware campaign use: Unknown" appears on all four entries. Across the whole catalogue as released on 23 September 2026, 1,360 of 1,721 entries carry Unknown and 361 carry Known. Unknown is the field's default state, an absence of a record rather than a record of absence, and reading it as "no ransomware crews are using this" turns a data gap into an assurance. A pre-authentication path traversal on a management server with a published hunting query is exactly the sort of thing that acquires a Known flag later.

"LivePatch" is the second. A live patching service is a genuine control and it closed CVE-2026-85102 at take 26. It does not close CVE-2026-93616, and Check Point says it never will for that flaw. An estate whose assurance model is "LivePatch is enabled and current" has, in this instance, a documented exception it will not discover by looking at LivePatch.

"Appliance mode" is the third. F5 states that BIG-IP in Appliance mode is also vulnerable to CVE-2026-94127. Appliance mode restricts the administrative shell; the flaw is in traffic handling on the data plane, so the restriction does not touch it.

Worth noting without sneering: Check Point's advisory opens by framing these fixes as part of its Frontier AI Readiness Program, and the hotfixes carrying the security content are the same accumulators that carry hardening improvements. That is a vendor putting a product narrative around a security release. It does not make the version tables wrong, and the version tables are the part you need.

What none of the four advisories states

The three questions a defender actually needs answered are whether exploitation preceded the patch, whether the affected interface was reachable from the internet in the cases that were observed, and whether usable indicators of compromise exist. Only one of the four answers the first question clearly, none answers the second, and all four answer the third to different depths.

Stated and not stated, read from Check Point sk1000117 and sk1000171, Arista advisory 0183 and F5 K000162605

CVE	Exploitation before the fix existed	Internet reachability in the observed cases
CVE-2026-93616	Stated, yes: attacks on 23 July, advisory and fix on 22 September	Not stated. Mitigation implies TCP/19009 may be widely reachable
CVE-2026-85102	Stated, no: no evidence of exploitation at the 9 September fix; attempts from 12 September	Not stated as such. The affected service is an internet facing VPN by design
CVE-2026-93952	Not stated. Actively exploited, no dates given	Not stated. Mitigation advises restricting the orchestrator web interface to trusted networks
CVE-2026-94127	Not stated. Exploitation confirmed, no date given	Not stated. Described as a data plane issue with no control plane exposure

On indicators, the picture is uneven. Arista publishes file paths, an MD5 hash, a request header and two attacker addresses, and warns there is no single definitive indicator. Check Point publishes two log searches for CVE-2026-93616 in sk1000171: one for an abnormally long username in a login request written to cpm.elg, correlated against a core dump generated at the same moment, and one for a resource loading error whose path contains traversal sequences. For CVE-2026-85102 it publishes three certificate subjects and tells you not to limit the search to them. F5 publishes a behavioural chain rather than any artefact.

None of the four publishes an attribution, a campaign name or a victim count beyond Check Point's "handful". Anyone telling you which group is behind this is going beyond the primary record.

What to do, in the order worth doing it

The question that exposes the gap

The reason the management plane keeps appearing in these catalogues is not that it is harder to write securely than a gateway. It is that it is the one box in the estate whose compromise needs no lateral movement. It already holds the policy, the logs, the certificates and the administrative credentials for everything downstream. It is the box most likely to be excluded from external scanning because it is "internal", and the box most likely to be excluded from internal scanning because it is "security infrastructure".

The honest close is not a warning about patching speed. Three days is achievable for a hotfix. The harder question is the one the 61 day interval makes unavoidable.

If your Check Point management server had been attacked on 23 July 2026, what in your estate would have recorded it, and would that record still exist on 25 September?

The hunting queries Check Point published look for an oversized username in an application log and a core dump generated at the same second. Both are the sort of artefact that rolls off in weeks. An organisation that can answer the question is one that ships management plane logs somewhere the management plane cannot reach. An organisation that cannot is being asked, by a three day deadline, to certify something it has no way of knowing.

Key facts