Check Point Management Server Zero-Day: 61 Days From Exploit to Fix

#cybersecurity #infosec #security

TL;DR

what: Check Point patched CVE-2026-93616 on September 22, a path traversal in the Security Management Server web service that attackers used for unauthenticated script execution in targeted attacks on July 23.
impact: The management server holds firewall policy for every gateway it manages, so code execution there is control of the ruleset, not a single host compromise.
fix: Install the fixed Jumbo Hotfix take listed in Check Point support article sk1000171, and note that LivePatch Take 28 or 29 from September 16 does not remediate this CVE.
who: Anyone running Security Management on R82.20, R82.10 Take 44 or below, R82 Take 126 or below, R81.20 Take 166 or below, or any end of support release, plus Spark and Security Gateway owners exposed to CVE-2026-85102.

Check Point patched a zero-day in its Security Management Server on September 22, 61 days after attackers used it. The company says a handful of targeted attacks on July 23 exploited CVE-2026-93616, a path traversal bug in the management server web service that lets an unauthenticated attacker upload and run scripts. Check Point rated it 9.8 out of 10 on CVSS. The management server is the box that holds firewall policy for every gateway it manages, so code execution there is not a single host compromise, it is control of the ruleset.

A path traversal that ends in script execution

The web service on the management server does not properly restrict which files and folders a request can reach. An attacker who can reach that service writes a script to a location the server will run, then triggers it. No credentials, no session, no prior foothold beyond network access to the web service.

Check Point's advisory does not say what network position an attacker needs, and that gap matters. A management server reachable only from an internal admin VLAN is a very different risk than one answering on a public address. The advisory also does not name the July targets, does not attribute the activity, and does not describe what the attackers did after exploitation. Hunting guidance and indicators of compromise are in support article sk1000171. Installing the fix tells you nothing about whether you were hit before it, so treat patching and hunting as two separate tasks with two separate owners.

⚠️ LivePatch Take 28 does not cover this — On September 16 Check Point fixed a different management server flaw, CVE-2026-91843, through LivePatch Take 28, or Take 29 on R82.20. Check Point says those takes do not remediate CVE-2026-93616. If your change record reads "LivePatch applied September 16" and the ticket is closed, the server is still exposed.

The version math catches people who already patched

Check Point numbers Jumbo Hotfix updates for each release by Take, and the LivePatch channel uses a separate take sequence. The CVE record lists these management server versions as affected:

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

Here is the trap. CVE-2026-85103, a VPN certificate flaw Check Point fixed on September 9, affected management servers as well as gateways. On R82.10, R82 and R81.20 the affected range for CVE-2026-93616 runs one take higher than the range for that September flaw. A server patched just far enough to clear the September 9 issue is still vulnerable to the September 22 one. Note also the disagreement in the source material: the CVE record qualifies R82.20 as affected only with no Jumbo Hotfix installed, while Check Point's own advisory lists R82.20 with no condition. Assume the broader reading until Check Point clarifies.

Second front: Spark firewalls under active probing

Since September 12, attackers have been trying to exploit CVE-2026-85102, a flaw in how Check Point gateways validate certificates while a VPN connection is being established. It may let an unauthenticated attacker run code on the gateway. Check Point shipped the fix on September 9 with no evidence of exploitation at the time. Three days later the attempts began, concentrated on Spark, the small business firewall line. That is the familiar sequence: the patch is the disclosure, and the window between release and weaponization is now measured in days.

Affected products are Security Gateway and Spark, 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 NCSC notes the flaw applies when these products use Site-to-Site VPN or Remote Access VPN. Check Point says the attempts arrived from anonymizing infrastructure including commercial VPN services and proxies, using certificates with these subjects:

CN=vpn,OU=users,O=global
CN=vpn-user,OU=users,O=global
CN=vpnuser,OU=users,O=global

That list is explicitly incomplete. Do not build a detection that only matches those three strings. Hunt on behavior instead: any certificate based Mobile Access login you cannot tie to a known user or a known source, followed by internal port and service scanning from the gateway's client pool. Check Point says customers who installed the September 9 fix are protected, but the advisory does not say whether any attempt succeeded.

If a gateway cannot be patched this week — For Site-to-Site VPN, the NCSC lists a Check Point workaround: turn off the implied VPN rules and permit UDP 500 and 4500 only from specific peer IP addresses. The workaround does not apply to locally managed Spark firewalls, which need the fix in sk1000117. Remote Access VPN gets no equivalent workaround, so those gateways are a patch or accept the risk decision.

What to do this week

Inventory every management server and record its release plus Jumbo Hotfix take, then compare against the affected list above rather than against your last change ticket.
Install the fixed build named in sk1000171. LivePatch takes from September 16 do not substitute for it.
Run the sk1000171 hunting guidance and indicator checks on every management server, including ones you patch, because patching erases nothing and proves nothing about July.
Confirm which gateways and Spark units are on the CVE-2026-85102 affected list and whether they run Site-to-Site or Remote Access VPN, then apply sk1000117 or the NCSC workaround.
Pull Mobile Access authentication logs back to September 10 and review every certificate based login, not only the three published subjects.
Check whether any management server web service is reachable from outside your admin network. The advisory does not define the required access path, so close it by policy.

Originally published on RedEye Threat Intelligence.

DEV Community