9/22/2026 • Security

Check Point Zero-Day Hit the Server That Manages the Firewall

Check Point has confirmed a CVSS 9.8 path traversal flaw in its Security Management Server was exploited in July, two months before a fix existed, and a second VPN flaw patched on 9 September is now being attacked too. Both are on CISA's exploited list.

Attackers broke into Check Point Security Management Servers on 23 July 2026. The fix arrived on 22 September. In between, nobody outside the attackers knew the hole existed. That is the uncomfortable timeline behind CVE-2026-93616, a CVSS 9.8 path traversal flaw that lets someone with no login upload and run scripts on the server that writes the rules for every Check Point firewall it manages.

In the same advisory, Check Point confirmed that CVE-2026-85102, the VPN certificate flaw we wrote about on 11 September, has moved from "no evidence of exploitation" to a wave of attacks against Quantum Spark customers worldwide, starting 12 September. On 22 September the US cyber agency CISA added both CVEs to its Known Exploited Vulnerabilities catalogue, with a remediation deadline of just three days for US federal agencies. That is about as loud as an alarm gets.

If your business runs a Check Point firewall, and especially if it runs its own Security Management Server rather than the Smart-1 Cloud service, this is worth an hour today.

What happened, in plain English

Two separate problems, and it helps to keep them apart.

CVE-2026-93616 is the new one, and it is a true zero-day. The management web service on a Check Point Security Management Server does not properly limit which files a request can reach (CWE-22, path traversal). An unauthenticated attacker can use that to drop a script onto the server and execute it, or load their own Java class. The vector is the worst case: reachable over the network, low complexity, no privileges, no user interaction. Check Point Research says it observed "a handful of pinpointed attacks" on 23 July 2026, which means the flaw was being used quietly for about two months before it was found and fixed.

It affects the Security Management Server, Multi-Domain Security Management Server, Log Server, Multi-Domain Log Server and SmartEvent on R82.20 (all builds), R82.10 with Jumbo Hotfix Take 44 or lower, R82 with Take 126 or lower, R81.20 with Take 166 or lower, and the end-of-support R81.10 with Take 190 or lower. R81, R80.40 and everything older are also affected and are out of support. Not affected: Smart-1 Cloud, the Security Gateway appliances themselves, and Quantum Spark firewalls. The bug lives in the manager, not the firewall.

Fixes are out: an R82.20 Security Hotfix, and Jumbo Hotfix Take 45 or later for R82.10, Take 127 or later for R82, Take 170 or later for R81.20, and Take 192 or later for R81.10. The important detail for anyone who read our last Check Point post: Check Point says no LivePatch will be available for this issue. Last time, customers with automatic LivePatch turned on were protected without lifting a finger. This time, someone has to install the fix.

If you cannot patch immediately, Check Point's advisory gives a mitigation: restrict access to TCP port 19009 on the management server to trusted addresses only, and configure Trusted Clients in SmartConsole so only internal IPs can reach management. It also lists two things to hunt for in the cpm.elg log: login attempts with unusually long usernames, and errors containing directory-traversal sequences like ../.

CVE-2026-85102 is the older one, and the story there has changed. This is the improper certificate validation flaw (CWE-295) in how Security Gateways and Quantum Spark firewalls handle VPN negotiation, also CVSS 9.8 and also unauthenticated. Fixes have been available since 9 September. On 12 September Check Point began seeing exploitation attempts against Spark customers globally, using certificates with tell-tale subjects such as CN=vpn, CN=vpn-user and CN=vpnuser. If you applied the September fix, or LivePatch applied it for you, you are protected. If you did not, your VPN gateway is now being actively probed. One nuance worth knowing: for site-to-site VPN, only gateways using certificate authentication are exposed. Pre-shared-key tunnels are not. Remote-access VPN is exposed regardless.

Why this one matters: the manager is the bigger prize

A firewall flaw gives an attacker one firewall. A management server flaw gives them the console that pushes policy to every firewall, holds the logs that would reveal them, and carries the admin credentials for the lot. Compromise the manager and you can quietly open a hole in the firewall, then erase the record of having done so. That is why a handful of targeted attacks on management servers should worry you more than a wave of noisy attempts against VPN gateways.

The second lesson is one we keep having to repeat, because the industry keeps proving it. On 4 September it was SonicWall's SMA 1000, exploited before a fix existed. Earlier this month it was Cisco's Firewall Management Center. Now Check Point. The pattern is not one vendor's carelessness. It is that management interfaces are complex web applications, they are routinely left reachable from places they should not be, and attackers have worked out that the control plane is where the leverage is.

The third lesson is about what "patched" means when the attack came first. A management server that receives the hotfix today but was reachable from the internet on 23 July may already have a visitor. Patching closes the door. It does not evict anyone who walked in before you closed it. That is why CISA flagged both entries for forensic triage, not just patching.

The honest bit

No vendor is immune, including the ones we like. We sell Cisco and Meraki gear, and Cisco's management platforms have featured in this series more than once this year. Check Point deserves credit on two counts here: it found the July intrusions itself rather than learning about them from a customer, and it published indicators, hunting guidance and a mitigation alongside the fix. That is the right way to handle a bad situation.

The genuine architectural point, offered as advice rather than a pitch, is about where your management plane lives. Check Point's own Smart-1 Cloud is not affected by this flaw, because the vendor patches the management service on its side. Cloud-managed platforms in general work the same way: the console is the vendor's to secure and to patch, and it never sits on your public IP for someone to find. We have written about why that model keeps improving after you buy it. If you run an on-premises management server of any brand, the equivalent discipline is simple to state and easy to neglect: it should never be reachable from the internet, full stop.

What we'd suggest you actually do

Work out which side of this you are on. Do you run an on-premises Security Management Server, Multi-Domain server, Log Server or SmartEvent? If so, CVE-2026-93616 applies to you. If you use Smart-1 Cloud, it does not, and you can skip to step 5.
Patch the management server now, by hand. Apply the R82.20 Security Hotfix or the Jumbo Hotfix take for your release listed above. Do not wait for LivePatch; Check Point has said there will not be one for this flaw.
Cut off exposure whether or not you have patched. Restrict TCP 19009 and management access to trusted internal addresses using SmartConsole's Trusted Clients. If your management server has ever been reachable from the public internet, treat that as a finding in itself.
Look for signs of a July visitor. Check the cpm.elg log for unusually long usernames in login attempts and for path-traversal sequences in error messages, as described in Check Point's sk1000171. If you find either, you are in incident-response territory, not patching territory, and it is time to get help.
Confirm the VPN fix landed. On every Security Gateway and Quantum Spark unit with a VPN, verify the September Jumbo Hotfix or Spark build from sk1000117 is installed, or that LivePatch applied it. Review Mobile Access logs for certificate logins using the CN=vpn, CN=vpn-user or CN=vpnuser subjects, and for any internal port scanning that followed a suspicious login.
If you are on an end-of-support release, R81.10 has a fix this time but is still out of support, and R81 and older have nothing coming. We have covered where that road leads. A no-login 9.8 with no patch is not a system to keep running.
Do the basics on every management interface. Unique admin credentials, multi-factor authentication where the platform supports it, access from a management network or VPN only, and a subscription to your vendor's advisories so this kind of news reaches you on day one.

The friendly takeaway

The headline is a zero-day, but the durable lesson is quieter. The most valuable box on your network is often not the firewall but the thing that tells the firewall what to do, and it tends to get less attention because it is one step removed from the internet. This month it was Check Point's turn to show that one step is not always enough.

As always, this post is part of us keeping watch so you don't have to. If you would like a second pair of eyes on your management plane, whether it is Check Point, Cisco, Meraki or something you inherited from a previous provider, get in touch. No obligation, no hard sell. Sometimes the useful answer is simply confirming that the console is not reachable from where it should not be.

What happened, in plain English

Why this one matters: the manager is the bigger prize

The honest bit

What we'd suggest you actually do

The friendly takeaway

References