ZERO-DAY EXPLOITATION · CVE-2026-93616

Check Point Management Server Zero-Day

61 Days From Exploit to Fix. Attackers ran unauthenticated code on Check Point Security Management Servers on July 23 using CVE-2026-93616, a 9.8 path traversal bug that Check Point only patched on September 22.

Matt Lucas  |  September 22, 2026  |  5 min
Editorial hero illustration
CVEs in this postCVE-2026-48842CVE-2026-76460CVE-2026-85102CVE-2026-85103CVE-2026-91843CVE-2026-93616CVE-2026-94127Live detections →All RedEye CVEs →
9.8
61 days
July 23 exploit to September 22 fix
3
attacker certificate subjects named
11
affected management server releases
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 / mitigation: 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's at risk: 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:

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:

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

cpinfo -y all 2>/dev/null | grep -iE 'jumbo|take|R8[0-2]'
clish -c "show version all"
clish -c "show installer packages installed"
fw log -n -p $FWDIR/log/fw.log | grep -iE 'CN=vpn,|CN=vpn-user,|CN=vpnuser,'

Questions about your exposure?

RedEye Security provides assessments for organizations that need to understand their real risk.

Talk to us