Breaking
SecurityDeveloping Story

Check Point Zero-Day Hit Management Servers

Attackers exploited a management server flaw in July while a separate VPN bug now draws ongoing attempts against small-business firewalls.

··2 hours ago·7 min read
a close up of a network with wires connected to it
Photo by Albert Stoynov on Unsplash

Check Point has disclosed that a previously unknown flaw in its Security Management Server was exploited in a small number of targeted attacks on July 23. The server is the component that holds and distributes firewall policy for the Check Point gateways it manages, which makes it a high-value target for anyone looking to reshape an organization's network defenses. A fix for the flaw, tracked as CVE-2026-93616, arrived on September 22.

Separately, Check Point said attackers have been trying since September 12 to exploit a VPN flaw it fixed on September 9, tracked as CVE-2026-85102. Those attempts have been aimed at customers of Spark, Check Point's firewall line for small businesses. When the September 9 fix shipped, Check Point said it had no evidence the flaw was being exploited in the wild.

Path Traversal With No Login Required

The management server bug is a path traversal issue in the server's web service. The service does not properly limit which files and folders a request can reach, which opens the door to an attacker uploading scripts to the server and then executing them. Check Point rated it 9.8 out of 10 on the CVSS scale in the CVE record for the flaw.

Access to the server's web service is the only precondition the advisory describes. An attacker who can reach that service can run scripts on the server without logging in, according to the company's account. Check Point's advisory does not name the targets of the July attacks or the attackers, nor does it say what the attackers did after exploiting the flaw.

The affected versions, as listed in the CVE record, span a long line of releases:

  • R82.20 with no Jumbo Hotfix installed
  • R82.10 with Jumbo Hotfix Take 44 or below
  • R82 with Jumbo Hotfix Take 126 or below
  • R81.20 with Jumbo Hotfix Take 166 or below
  • R81.10 with Jumbo Hotfix Take 190 or below (end of support)
  • R81, R80.40, R80.30, R80.20, R80.10 and R80 (all end of support)

Check Point's own advisory lists R82.20 as affected without the "no Jumbo Hotfix" condition that appears in the CVE record.

Overlapping Fix Windows Create a Trap

On September 16, Check Point fixed a separate flaw in the management server, CVE-2026-91843, through its LivePatch channel. That update was LivePatch Take 28, or Take 29 on R82.20, according to a summary of Check Point's advisory by France's CERT Santé. Check Point said those LivePatch takes do not fix CVE-2026-93616.

There is a related wrinkle for administrators who thought they were already clear of trouble. CVE-2026-85103, a VPN certificate flaw that Check Point fixed on September 9, affected both gateways and management servers. On R82.10, R82, and R81.20, the new flaw's affected list goes one take higher than that flaw's list. A server that was updated just enough to move outside the September flaw's range is therefore still affected by CVE-2026-93616.

Check Point numbers Jumbo Hotfix updates for each release by "Take." Its LivePatch channel, which pushes urgent fixes, uses a separate set of take numbers. That split is what makes the comparison easy to get wrong: two fixes delivered around the same time can sit under different numbering schemes, and being current on one channel does not imply being current on the other.

What Administrators Should Check

The fixed builds, along with Check Point's guidance on mitigation, hunting, and indicators of compromise, are collected in support article sk1000171. The company's instructions for management server administrators are short and specific:

  • Check the server's release and Jumbo Hotfix take against the affected list.
  • Install the fix listed in sk1000171.
  • Use the hunting guidance and indicators of compromise in sk1000171 to look for signs of an attack.

One point in that guidance matters more than it might appear at first read. Installing the fix does not show whether the server was attacked before. Patching closes the door; it does not answer whether anyone walked through it while it was open. Administrators who want that answer have to go looking through logs and other artifacts rather than assuming a clean patch means a clean history.

Check Point's advisory names only Security Management as affected and does not say what network access an attacker needs. The Hacker News has asked Check Point about other affected products, the fixed builds, and the July attacks.

The VPN Flaw Under Active Attempts

CVE-2026-85102 sits in the way Check Point gateways check certificates while a VPN connection is being set up. It may let an attacker who has not logged in run code on the gateway. Fixes have been available since September 9 and are documented in support article sk1000117.

The affected products are Security Gateway and Spark firewalls, whether centrally or locally managed, on R81 and R81.10 (both end of support), R81.10.x, R81.20, R82, R82.00.x and R82.10. The Netherlands' National Cyber Security Centre says the flaw applies when these products use Site-to-Site VPN or Remote Access VPN.

Check Point said the attempts came from anonymizing infrastructure, including VPN services and proxies. The attackers used certificates with these subjects:

  • Certificate subject: CN=vpn,OU=users,O=global
  • Certificate subject: CN=vpn-user,OU=users,O=global
  • Certificate subject: CN=vpnuser,OU=users,O=global

That list is not complete, and other subjects may be in use. Administrators should check logs for any unusual certificate-based Mobile Access login, not only those carrying the subjects above. They should also check what suspicious Mobile Access users do after logging in, which often includes scanning internal ports and services.

Check Point says customers who installed the September 9 fix are protected, but its advisory does not say whether any attempt succeeded.

A Workaround for Unpatched Gateways

For gateways that cannot be patched yet, the Dutch national cyber security center lists a Check Point workaround for Site-to-Site VPN: turn off the implied VPN rules and allow UDP ports 500 and 4500 only from specific peer IP addresses. The workaround does not apply to locally managed Spark firewalls. Mitigation steps from Check Point are in sk1000117.

The distinction between the two flaws is worth keeping straight. The management server flaw was exploited in attacks on July 23, and the company did not put out a fix until September 22. The VPN flaw has drawn exploit attempts since September 12 against products that had a fix available since September 9, which shifts the exposure question from whether a patch exists to whether it was applied.

The Response Timeline

Laid end to end, the sequence runs like this. A management server flaw, CVE-2026-93616, was exploited in targeted attacks on July 23 and fixed on September 22. A VPN certificate flaw, CVE-2026-85102, was fixed on September 9, with the company saying at the time it had no evidence of exploitation. A separate management server flaw, CVE-2026-91843, was fixed through LivePatch on September 16. Exploit attempts against the VPN flaw began on September 12 and have targeted Spark customers.

Two of the four items involve the same product family and the same general class of weakness, though Check Point describes them as distinct flaws with distinct fixes. The company's own note that the September 16 LivePatch takes do not fix CVE-2026-93616 means an administrator tracking only the most recent advisory could conclude the management server is handled when it is not.

There is another loose end in the public record. Check Point's advisory names Security Management as the only affected product for the zero-day, but the company does not describe what level of network access an attacker needs to reach the vulnerable web service. That omission leaves administrators to work from their own architecture when judging how exposed a given management server is.

Why This Matters for Defenders

The two flaws put different pressures on different teams. Management servers rarely sit on the open internet, so the zero-day's exploitation in July suggests either that the attackers had a foothold already or that the servers were reachable in ways their operators may not have expected. Either way, patch status alone will not tell an affected organization whether it was among the July targets; the hunting guidance in sk1000171 is the only path to that answer, and it has to be run deliberately.

The VPN flaw is the more broadly relevant of the two for small businesses, because Spark is aimed at that market and because the affected product list includes end-of-support releases. Organizations still running R81 or R81.10 face a choice between upgrading and applying the workaround, and the workaround's exclusion of locally managed Spark firewalls narrows it further for exactly the customers least likely to have a dedicated security team.

For anyone running Check Point infrastructure, the practical near-term steps are the ones the advisories already name: reconcile each server's release and hotfix take against the affected lists, install the fix in sk1000171, and run the hunting guidance rather than treating installation as an all-clear. For the VPN side, checking logs for unusual certificate-based Mobile Access logins — not just the three known subjects — is the step most likely to surface attempts that used different certificate details. The company's public accounts leave open whether any of those attempts succeeded, which means the log review is doing work that no advisory can do for the reader.

#check point#zero-day#vpn#vulnerability#network security#patching

Sources

Iliyas

Founder & Editor, Xploitwire

This article was written and reviewed against the sources listed above before publication, under editorial policies set by Iliyas. Read our Editorial Policy →

← Back to all stories