Four Exploited Zero-Days in One Week: Check Point, F5 BIG-IP APM and Arista VeloCloud Explained

In the last full week of September 2026, four vendors disclosed that attackers were already inside products whose entire job is to keep attackers out. A Check Point management server. A Check Point VPN gateway. An F5 access proxy. An Arista SD-WAN orchestrator. CISA added all four to its Known Exploited Vulnerabilities catalog on 22 September and gave US federal agencies until 25 September to fix them. Three days.

Four unrelated vendors, one week, one deadline. This article explains what each flaw actually does, which builds carry the fix, and how to check whether you were already hit. It ends with the question none of the four advisories asks.

Why these four belong in one article

Most weeks of vulnerability news are a list of unrelated bugs that happen to share a date. This week is not that. These four products sit in different racks from different vendors, but they occupy the same position in a network: none of them is the thing you are protecting. Each one is the thing that decides who reaches what you are protecting.

It is worth being concrete about what lives in each box:

• A Check Point Security Management Server holds the policy for every gateway it manages, along with the logs that would show someone tampering with it. Own the management server and you do not need to attack the firewalls; you can simply tell them what to allow.
• A VPN gateway is where an untrusted network becomes a trusted one. It terminates the tunnel, validates the certificate and decides that the person on the other end is an employee.
• An F5 BIG-IP APM configured as an OAuth authorization server issues the tokens that other applications accept as proof of identity. Applications behind it trust its answer by design.
• A VeloCloud Orchestrator programs every branch edge in an SD-WAN fabric. It is the single console that pushes routing and security configuration to sites that may have no local IT staff at all.

An attacker who lands on any one of these does not have to break anything else. They inherit the authority the device already had. That is why a pre-authentication flaw in this layer is worth more to an attacker than a far more severe bug in an ordinary application server, and it is why all four moved from disclosure to a three-day federal deadline so quickly.

CVE-2026-93616: two months inside Check Point’s management server

Check Point’s Security Management Server is the console administrators use to write firewall policy and the place logs are collected and reviewed. It is normally treated as an internal system, which is exactly why the next sentence matters.

The flaw is a pre-authentication path traversal combined with a file upload. An attacker who can reach the management interface, with no credentials at all, can write a file outside the directory the upload was meant for and then get it executed as a script. That is full compromise of the box that defines your security policy and stores the evidence of what happened on it.

Read that as an attacker would. Policy authority and log custody in the same place means the intruder can both open a path and edit the record of having done so. Check Point reports exploitation going back to 23 July 2026, roughly two months before the advisory. Anyone treating this as a patch-and-move-on item is skipping the harder question of what happened during those two months.

If you cannot apply the hotfix immediately, Check Point’s interim guidance is to restrict management server access to trusted internal addresses. That is worth doing regardless of patch state, because a management server that answers from the open internet is a finding in its own right. Confirm the exact take for your deployment against sk1000171 before scheduling the change; the hotfix take numbers differ per train and Check Point has revised them.

# On the management server, look for recently written or unexpected files in
# web-served and upload directories. A pre-auth upload flaw leaves artifacts on disk.
find /var/log /opt/CPsuite-R8*/fw1/log -type f -newermt '2026-07-20' \
  \( -name '*.php' -o -name '*.sh' -o -name '*.pl' -o -name '*.cgi' \) -ls

# Unexpected outbound connections from the management server are a strong signal:
# this box should talk to gateways and your update source, not to the internet at large.
netstat -anp | grep ESTABLISHED

# Review administrator accounts and recent policy installs for entries nobody recognises.
# Compare against your change records, not against memory.

CVE-2026-85102: when a gateway trusts a certificate it should have rejected

The second Check Point flaw is in the gateway rather than the console, and it is a different class of mistake. During VPN negotiation the gateway validates the certificate the client presents. It does that validation improperly, which lets an unauthenticated remote attacker execute code on the gateway itself.

A certificate is a claim of identity, and the whole security of certificate-based VPN rests on the gateway checking that claim strictly. When the check is wrong, the attacker does not need a stolen credential, a phished password or a session token. They present something the gateway should refuse, and it does not refuse.

The timeline here is unusual and worth noting. Check Point disclosed the issue and shipped fixes on 9 September 2026. Exploitation at scale against Spark customers began on 12 September, three days after the fix existed. The attackers, in other words, were reading the advisory. This is the normal pattern now: publication of a fix for an edge device is itself the starting gun, and the window between patch availability and mass exploitation is measured in days.

One caveat that matters operationally: the mitigation Check Point provides applies to centrally managed Spark firewalls. Locally managed units need the firmware itself. If you have branch or retail sites running Spark boxes that nobody has logged into for a year, those are the units at risk and the ones least likely to be on anybody’s patch list.

# Look for certificate-based Mobile Access logins that do not match a real user.
# Do not stop at the handful of account names published in write-ups -- an attacker
# picks arbitrary names, so review the full set of certificate logins in the window.
#   SmartConsole > Logs & Monitor > New Tab > Log View
#   Filter:  blade:"Mobile Access" AND auth_method:"Certificate"

# A compromised gateway usually starts looking around. Mobile Access users scanning
# internal ports or enumerating internal services is the clearest sign of that.
#   Filter:  blade:"Mobile Access" AND (service:* AND action:"Drop")

# Review the window from 12 September 2026 onward at minimum.

CVE-2026-94127: F5 BIG-IP APM, but only if it hands out OAuth tokens

BIG-IP Access Policy Manager is F5’s access proxy. It sits in front of applications and decides who may reach them. In some deployments it goes further and acts as an OAuth authorization server, meaning it issues the access tokens that downstream applications accept as proof that a user is who they say they are.

The flaw is a heap-based buffer overflow reachable without authentication, and it leads to remote code execution. F5 patched it as a zero-day on 22 September 2026 after confirming exploitation in the wild.

The most important detail in this advisory is a conditional, and it cuts both ways. The system is vulnerable only when a virtual server is configured with both an access policy and an OAuth profile, that is, when APM is acting as an OAuth authorization server. Most BIG-IP deployments are not configured that way, so the blast radius is narrower than the CVSS score alone suggests. But the deployments that are configured that way are precisely the ones issuing identity tokens for other systems, which makes a compromise there unusually valuable. Narrow exposure, high consequence.

If you cannot take the upgrade immediately, F5 offers an iRule-based mitigation for the affected virtual server, obtained through F5 support rather than published openly. Check your configuration first: if no virtual server pairs an access policy with an OAuth profile, you are not exposed to this one, and you can schedule the upgrade normally instead of treating it as an emergency.

# 1. OAuth failures with a null source ID are the signature of the attack attempt.
grep 'Request UserInfo from Source ID (null) IP' /var/log/apm

# 2. A sharp rise in failed OAuth operations.
tmctl global_oauth_stat    # inspect the total_failed counter

# 3. Commands appearing in the audit log shortly after those OAuth failures.
grep -iE 'bash|curl|wget|nc |python' /var/log/audit

# 4. TMM core files. A crash loop ending in SIGABRT alongside the above is the
#    sequence worth escalating to a human immediately.
ls -l /var/core/ 2>/dev/null

# The pattern to escalate: repeated OAuth failures, then unexpected commands,
# then a TMM SIGABRT, within a short window.

CVE-2026-93952: the orchestrator that programs every branch

VeloCloud Orchestrator is the management plane of a VeloCloud SD-WAN, now part of Arista. It is the console that pushes configuration to every edge device in the fabric, including sites with no technical staff on the ground. Compromising it is not equivalent to compromising one branch; it is equivalent to having configuration authority over all of them.

The flaw is improper input validation that lets a remote attacker reach privileged internal functionality on the orchestrator host. Arista rates it 10.0 on the CVSS 3.1 scale and 9.5 on CVSS 4.0, and confirms active exploitation. Arista has patched its hosted orchestrators; on-premises deployments are the ones that need attention.

Exploitation without operator or tenant credentials requires three conditions to hold at once: certificate-based edge-to-orchestrator authentication is enabled, the attacker has obtained the public portion of an edge certificate, and the orchestrator web interface is reachable. The third condition is the one you control most directly, and it is the one an attack-surface review would have surfaced long before this advisory existed.

Two of the four branches had no fix when the advisory went out. If you run 6.1.x or 7.0.x on-premises, patching is not available to you as an immediate answer, and the practical control is to take the orchestrator web interface off any network it does not strictly need to answer on while you wait. Check the advisory for updated build availability before assuming that is still true.

What the four have in common, and why that matters more than any one of them

Taken individually these are four vendor advisories to schedule. Taken together they describe how intrusions actually start in 2026, and four patterns repeat across all of them.

• Every one is pre-authentication. None of these required a stolen password, a phished session or an insider. The attacker reaches the device and that is enough, which means every control that depends on identity is downstream of the failure.
• Every one is in the control plane, not the workload. The compromised asset in each case is the thing that grants access, distributes policy or issues tokens. The attacker inherits authority rather than having to escalate to it.
• Dwell time is measured in months, not hours. The Check Point management flaw was being exploited from 23 July and disclosed on 22 September. For two months the correct answer to the question were we breached was yes, and no advisory existed to prompt anyone to ask.
• Exposure is conditional, and the conditions are configuration you may not remember choosing. F5 is only vulnerable when APM runs as an OAuth authorization server. VeloCloud needs certificate-based edge authentication and a reachable web interface. Answering whether you are affected means knowing how these systems are configured today, not how they were designed years ago.

The fourth pattern is the one that hurts. In each case the question is not simply do we run this product. It is do we run this product, in this configuration, reachable from where. Most organisations cannot answer that within the three days CISA allowed.

The part auditors test: this is a controls story

If you carry SOC 2, ISO 27001 or PCI DSS, this week was not only an incident-response exercise. It exercised named controls, and the evidence of how you responded is what an auditor will ask for. A week in which four exploited flaws hit your perimeter is a direct test of whether your vulnerability management and monitoring controls work in practice or only on paper.

The practical point is that the artifacts you need for an audit are the same artifacts you need for the incident: dated evidence that you knew what you exposed, learned about the flaw, acted within your stated window, looked for signs of compromise, and wrote down what you found. Teams that generate those continuously answer this week in an afternoon. Teams that generate them before an audit spend the week reconstructing.

What to do this week

• Inventory before you patch. List every Check Point management server, Check Point gateway or Spark unit, F5 BIG-IP, and VeloCloud Orchestrator you operate, including the ones at branch sites and the ones inherited through acquisitions. You cannot patch what is not on the list.
• Answer the configuration question for each. For F5, does any virtual server pair an access policy with an OAuth profile. For VeloCloud, is certificate-based edge authentication on and is the web interface reachable. These answers decide whether you have an emergency or a scheduled change.
• Patch to the builds in the tables above, confirming the exact hotfix take or build against the vendor advisory for your train, since several have been revised since publication.
• Where no fix exists, reduce reachability. Restrict the Check Point management server to trusted internal addresses. Take the VeloCloud 6.1.x or 7.0.x orchestrator interface off networks it does not need. Request the F5 iRule mitigation from support.
• Hunt before you close the ticket. Run the checks above over a window that starts well before disclosure. For CVE-2026-93616 that means going back to July, not to last week.
• Write down what you did and when. That record is your audit evidence for the vulnerability-management and incident-response controls, and it is far easier to capture now than to reconstruct in six months.

The question none of these advisories asks

Every one of these advisories tells you what to patch. Not one tells you whether the affected device is reachable from the internet right now, or which version it is running, or whether it is a box someone stood up for a project three years ago and never decommissioned. That question is yours, and it is the one that determines whether a week like this is an afternoon of scheduled changes or a scramble.

The recurring lesson across this year’s edge-device advisories is not that any single vendor is careless. It is that organisations consistently discover what they expose at the moment an advisory forces the question. Continuous attack-surface monitoring discovers what you expose to the internet, including appliances like these, and the software versions they present, so the next advisory arrives as a lookup rather than a fire drill. Pairing it with continuous control monitoring means the patch window and the evidence of meeting it are recorded as they happen, which is what an auditor asks for later.

Frequently asked questions

What is CVE-2026-93616?

A CVSS 9.8 pre-authentication directory traversal with file upload in Check Point Security Management Server, Multi-Domain Security Management Server, Log Server, Multi-Domain Log Server and SmartEvent. An unauthenticated attacker who can reach the management interface can upload and execute arbitrary scripts on it. Check Point observed exploitation from 23 July 2026 and CISA added it to the KEV catalog on 22 September 2026.

What is CVE-2026-85102?

A CVSS 9.8 improper certificate trust validation flaw in Check Point gateways. During VPN negotiation the gateway validates the presented certificate incorrectly, allowing an unauthenticated remote attacker to execute code on the gateway. Check Point shipped fixes on 9 September 2026 and observed a wave of exploitation against Spark customers from 12 September. Fixed firmware is R82.00.10 build 2325 or R81.10.17 build 4968.

What is CVE-2026-94127?

An unauthenticated remote code execution flaw in F5 BIG-IP Access Policy Manager caused by a heap-based buffer overflow. F5 and CERT-EU rate it CVSS 9.8; NVD records 9.3 on the CVSS 4.0 scale. It only affects systems where a virtual server is configured with both an access policy and an OAuth profile, meaning APM acts as an OAuth authorization server. Affected versions are 17.1.0 to 17.1.3, 17.5.0 to 17.5.1, and 21.1.0.

What is CVE-2026-93952?

An improper input validation flaw in Arista VeloCloud Orchestrator that lets a remote attacker reach privileged internal functionality on the orchestrator host. It is rated 10.0 on CVSS 3.1 and 9.5 on CVSS 4.0 and is confirmed exploited. Fixed builds are 5.2.3.16 and 6.4.2.8; the 6.1.x and 7.0.x branches had no fixed build when the advisory was published.

Am I affected by the F5 BIG-IP flaw if I run an affected version?

Not necessarily. CVE-2026-94127 is only exploitable when a virtual server has both an access policy and an OAuth profile configured, that is, when BIG-IP APM is acting as an OAuth authorization server. If no virtual server is configured that way, running an affected version does not expose you to this particular flaw. Check the configuration before treating it as an emergency, and upgrade on your normal schedule if you are not exposed.

How do I check whether these flaws were already exploited against me?

For Check Point management servers, look for unexpected script files written into web-served or upload directories and for outbound connections the server should not be making, going back to at least 20 July 2026. For Check Point gateways, review Mobile Access logs for certificate-based logins that do not match real users and for Mobile Access users scanning internal services. For F5, look in /var/log/apm for OAuth UserInfo failures with a null source ID, a rise in the total_failed counter from tmctl global_oauth_stat, unexpected commands in /var/log/audit shortly afterwards, and TMM core files. Hunt over a window starting before the disclosure date, not after it.

Why were all four added to CISA KEV on the same day?

CISA adds vulnerabilities to the Known Exploited Vulnerabilities catalog when it has reliable evidence of active exploitation. All four were confirmed exploited in the wild in the same period, and all four sit in network control-plane devices where compromise grants broad authority. They were added on 22 September 2026 with a remediation deadline of 25 September 2026 for US federal civilian agencies. The catalog is public and widely used as a prioritisation source outside government as well.

What should we do if no patch exists for our version?

Reduce reachability while you wait. For VeloCloud Orchestrator on 6.1.x or 7.0.x, where no fixed build existed at publication, take the web interface off any network that does not strictly need it. For Check Point management servers, restrict access to trusted internal addresses. For F5, request the iRule-based mitigation from F5 support. In every case, hunt for signs of prior compromise rather than assuming that being unpatched means being untouched, and re-check the vendor advisory for newly published builds.