Check Point Zero-Day Puts Firewall Management Servers on a Three-Day Patch Clock

Check Point has released emergency fixes for a critical Security Management vulnerability that attackers exploited before a patch was available. The flaw, CVE-2026-93616, lets an unauthenticated attacker reach outside an intended directory, upload a script and execute it on a management server. It can also be used to load an arbitrary Java class.

The company disclosed the CVSS 9.8 zero-day on September 22 after identifying a small number of targeted attacks on July 23. The same alert confirmed a separate wave of exploitation against Check Point Spark firewalls through CVE-2026-85102, a pre-authentication VPN certificate-handling flaw that can lead to remote code execution.

CISA added both vulnerabilities to its Known Exploited Vulnerabilities catalog on September 22 and set a September 25 remediation deadline for U.S. federal agencies. That unusually short window reflects more than a high severity score: both bugs are being used in attacks, and CISA requires forensic triage as well as mitigation under Binding Operational Directive 26-04.

Organizations running Check Point infrastructure should split the response into two tracks. Security Management, Multi-Domain Management, Log Server and SmartEvent systems need the new September 22 fix for CVE-2026-93616. Gateways and Spark firewalls using site-to-site or remote-access VPN need the September 9 fix for CVE-2026-85102. Installing one does not necessarily resolve the other.

Why the management-server flaw has an outsized impact

A Security Management Server is the control plane for Check Point gateways. It stores security objects and policy configuration, distributes policy and provides administrative visibility. A firewall appliance may not be directly vulnerable to CVE-2026-93616, but a compromised management server can still put the integrity of the policies sent to that firewall in doubt.

The vulnerable management web service does not properly constrain file paths. According to Check Point’s advisory, an attacker can exploit the path traversal before authentication to execute a script from an arbitrary location and load a Java class. Check Point has not publicly identified the victims or threat actor, and it has not described the attackers’ post-exploitation activity.

The affected scope is broader than a single management-server label. Check Point’s technical guidance covers Security Management Server, Multi-Domain Security Management Server, Log Server, Multi-Domain Log Server and SmartEvent. Smart-1 Cloud has already been patched. Standalone systems that combine management and firewall functions are affected on the management side.

Administrators should avoid assuming that the flaw guarantees root access or immediate control of every managed gateway; the public evidence does not establish that. The confirmed capability is serious enough on its own, however. Code execution on a central policy and logging system creates plausible paths to configuration theft, policy manipulation, evidence tampering, persistence and movement into adjacent systems.

Which Check Point versions need an update

The fixed Jumbo Hotfix level differs by release. Check Point’s September 22 guidance identifies the following affected and remediated versions:

Two versioning details can easily trip up a rushed response. First, the fixed numbers are not always the next sequential take shown in the affected range: R81.20 moves from an affected Take 166-or-earlier range to fixed Take 170, while R81.10 moves from Take 190-or-earlier to Take 192. Do not treat an omitted intermediate build as protected.

Second, Check Point LivePatch Take 28 and Take 29 do not fix CVE-2026-93616. The company says no LivePatch will be released for this vulnerability because of the nature of the correction. An environment that applied a recent LivePatch for a different management flaw still needs the applicable Security Hotfix or Jumbo Hotfix for this one.

Restrict TCP port 19009 while patching

The vulnerable service must be reachable for an attacker to exploit it. Check Point’s community guidance identifies TCP port 19009 as the access point to restrict while teams deploy the permanent fix. Allow it only from administrative sources that genuinely require access, and check every route to the server: internet exposure, VPN access, general internal networks, management networks and alternative interfaces.

In Check Point policy, review Manage & Settings > Permissions & Administrators > Trusted Clients and narrow the client list to known administrative addresses or subnets. Also inspect the effective policy on the gateway protecting the management server, including implied control rules. A broad internal network is not a safe substitute for a dedicated management segment; an already compromised workstation inside that network could still reach the service.

Restricting the port is containment, not remediation. It reduces who can reach the vulnerable component but does not remove the vulnerable code, and it cannot answer whether the server was compromised before the rule changed.

Hunt back to at least July 23

Check Point’s support article provides two checks for CVE-2026-93616. Run them in Expert mode on every affected management, multi-domain, logging and SmartEvent server. Preserve the output and relevant files before making wider incident-response changes.

The first check searches management logs for a login request containing an abnormally long username:

grep -nHP "login\(loginRequest=LoginRequest\{authenticationInfo=AuthenticationInfoBase\{username='[^' ]{1001,}'" "$MDS_FWDIR"/log/cpm.elg*

If it returns a result, look for FWM or MDS process dumps:

ls -l /var/log/dump/usermode/ | grep -e fwm -e mds

Match the timestamp of a long-username login attempt with the dump time. Check Point describes a match as a possible exploitation attempt, not proof that arbitrary code ran.

The second search looks for resource-loading errors involving suspicious paths:

grep -E "ERROR.*upgrade\.base\.ReflectionUtils.*Failed to load allResourceFiles map from" $MDS_FWDIR/log/cpm.elg*

Investigate returned paths for traversal sequences such as ../, unexpected references to /tmp, or other locations outside the normal application directory. A clean result is not conclusive. Log rotation, limited retention, unsearched compressed files, collection errors and attacker tampering can all hide earlier activity.

The investigation window should reach back to at least July 23, the date Check Point observed targeted exploitation, rather than beginning on the September 22 disclosure date. Where evidence permits, also review administrative-object changes, policy publications, policy installations, new or modified scripts, unexpected Java classes, outbound connections and credentials or keys accessible from the server.

If either check produces a suspicious result, treat the system as an incident. Preserve logs, dumps and files with timestamps and hashes; contain network access; assess exposed secrets; and work with Check Point Support or an incident-response team on recovery. Applying the hotfix closes the vulnerability but does not remove persistence or restore trust in policies and logs that may already have been altered.

Spark VPN exploitation needs a separate check

CVE-2026-85102 affects certificate validation during VPN negotiation on Security Gateway and centrally or locally managed Spark Firewall products. Check Point fixed it on September 9, before it had evidence of attacks. The company later observed exploitation attempts against Spark customers worldwide beginning September 12.

The attacks used anonymizing services and certificates with subjects including CN=vpn,OU=users,O=global, CN=vpn-user,OU=users,O=global and CN=vpnuser,OU=users,O=global. Those values are useful leads, not a complete detection rule. Administrators should review all unusual certificate-based Mobile Access logins and follow-on behavior from the associated users, especially internal port and service scanning.

Gateways and Spark firewalls using site-to-site or remote-access VPN should be checked against Check Point advisory sk1000117. The company says systems with the September 9 fix are protected. For CVE-2026-93616, use sk1000171 for the current builds, validation commands, indicators and recovery guidance; those details may change as the investigation develops.

A practical response order

1. Inventory every Check Point management, multi-domain, logging, SmartEvent, gateway and Spark system, including standalone appliances.
2. Record each release, Jumbo Hotfix take and LivePatch state. Do not count LivePatch Take 28 or 29 as protection from CVE-2026-93616.
3. Restrict TCP/19009 to necessary administrative sources and review implied rules while the management hotfix is deployed.
4. Install the fixed Security Hotfix or Jumbo Hotfix on affected management systems, then verify the running take rather than relying on the change ticket alone.
5. Run Check Point’s management-server hunting checks and review historical evidence back to at least July 23.
6. Confirm the September 9 VPN fix on affected gateways and Spark firewalls, then hunt for anomalous certificate logins and internal scanning from Mobile Access sessions.
7. Escalate any indicator to incident response. Patching and compromise assessment are separate jobs.

The immediate deadline matters, but the deeper lesson is architectural. Management servers and VPN gateways are high-leverage systems: one distributes trust and policy across the environment, while the other sits on an untrusted network boundary. Both need rapid patching, narrow reachability and retained forensic evidence strong enough to answer what happened before the update arrived.