- September 22, 2026
Critical Path Traversal Vulnerability in Check Point Management Servers Under Active Exploitation (CVE-2026-93616)
A critical pre-authentication path traversal flaw in Check Point Management Servers lets remote attackers upload and run arbitrary scripts on the system that administers enterprise firewall policy, and attackers have been exploiting it since July
Executive Summary
On September 22nd, 2026, Check Point released emergency hotfixes for a critical vulnerability in its Management Server products and confirmed that attackers had already exploited it as a zero-day. Tracked as CVE-2026-93616, the vulnerability allows an unauthenticated remote attacker to traverse outside the intended directory in the Management web service and upload scripts to execute on the server. CISA added the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog the same day.
The Management Server is the central administrative plane for a Check Point deployment. It stores and distributes security policies to manage gateways and collects logs across the enterprise network. This allows an attacker who executes code there to control firewall policy and gain access to operational and audit data, which the organization relies on to detect an intrusion. Check Point observed the earliest attacks on July 23rd, 2026, described the activity as targeted and limited, and stated it is aware of a handful of customers who were attacked. The vendor has not attributed the intrusions or described what the attackers did after gaining code execution.
Active exploitation is confirmed, and this is the latest in a run of Check Point management and gateway flaws that attackers have leveraged over the past year. Given the privileged position of the Management Server and the confirmed exploitation preceding the fix, Beazley Security recommends affected organizations apply available fixes immediately and conduct a thorough review for any signs of compromise.
Affected Systems or Products
The vulnerability affects Security Management Server, Multi-Domain Security Management Server, Log Server, Multi-Domain Log Server, and SmartEvent.
Release | Affected Versions |
|---|---|
R82.20 | No Jumbo Hotfix installed |
R82.10 | Jumbo Hotfix Take 44 and below |
R82 | Jumbo Hotfix Take 126 and below |
R81.20 | Jumbo Hotfix Take 166 and below |
R81.10 | Jumbo Hotfix Take 190 and below (end of support) |
R81, R80.40, R80.30, R80.20, R80.10, R80 | All versions (end of support) |
Smart-1 Cloud is not vulnerable, as Check Point has already applied the fix.
Check Point Firewall Appliances and Spark Firewalls are not affected by this issue.
Mitigations / Workarounds
Upgrading is the only complete remediation. Administrators should not assume LivePatch protects them: LivePatch Takes 28 and 29 do not correct this flaw, and Check Point states no LivePatch will be available given the nature of the fix.
Where organizations cannot patch immediately, the following steps reduce exposure:
- 1.
Place the Management Server behind a Security Gateway or Check Point firewall and restrict access to TCP port 19009 to trusted IP addresses.
- 2.
Limit the Trusted Clients list to known internal administrative addresses via Manage & Settings > Permissions & Administrators > Trusted Clients in SmartConsole.
Treat both as temporary measures. Because Check Point has asserted exploitation predated the fix, applying the hotfix takes priority over access controls alone, and patching does not reveal whether a server was already attacked.
Patches
Check Point has released fixes. Customer-managed servers require the R82.20 Security Hotfix or a corrected Jumbo Hotfix Accumulator, with the correction included in R82.10 Take 45, R82 Take 127, R81.20 Take 170, and R81.10 Take 192 or later.
Vendor-hosted Smart-1 Cloud instances have already been updated.
Fixed builds, hunting guidance, and indicators are published in Check Point support article sk1000171 and the accompanying vendor advisory.
Indicators of Compromise
Hunt across every management, logging, and SmartEvent server, not only those exposed to the internet.
Check Point provided the following two checks for compromise:
- 1.
Look for unusually long usernames recorded in the
cpm.elglogs, and then correlate those entries against FWM or MDS core dumps generated around the same time.
grep -nHP "login\(loginRequest=LoginRequest\{authenticationInfo=AuthenticationInfoBase\{username='[^' ]{1001,}'" "$MDS_FWDIR"/log/cpm.elg*
If that search returns results, validate if a FWM/MDS core dump was generated at the same time.
ls -l /var/log/dump/usermode/ | grep -e fwm -e mds
The presence of a core dump at the same time as the login attempt indicates potential exploitation.
- 1.
Search for ReflectionUtils errors reporting that the service failed to load an allResourceFiles map. Examine the paths returned by those errors for traversal sequences, such as
../../. Either pattern warrants immediate investigation.
grep -E "ERROR.*upgrade\.base\.ReflectionUtils.*Failed to load allResourceFiles map from" $MDS_FWDIR/log/cpm.elg*
Where either pattern appears, preserve the relevant logs and core dumps before they are overwritten or removed, isolate the affected server where operations allow, review what the server did afterward, and contact Check Point Support.
Check Point has claimed it will continue to update its advisory, so administrators should monitor it for revised guidance and additional indicators, and watch for official communications from Check Point about specific exploitation within their cloud userbase.
Technical Details
CVE-2026-93616 combines directory traversal with unsafe file upload handling in the Check Point Management web service. The service does not properly constrain which files and directories a request can reach. By manipulating the file path in a request with relative paths, an attacker causes the service to write a script to an arbitrary location. This also enables execution to load an arbitrary Java class.
Check Point has withheld deeper technical detail and has not described the payloads used in the July attacks. No public proof-of-concept (PoC) exploit is available at the time of writing. However, because exploitation of this vulnerability appears trivial, we would expect public PoC examples in the upcoming days.
How Beazley Security is responding
Beazley Security is monitoring client perimeter devices through our Exposure Management Platform to identify impacted devices and support organizations in remediation of any issues found.
We are also conducting threat hunts across our MDR environment to detect potential exploitation attempts against our clients.
If you believe your organization may have been impacted by this attack campaign and need support, please contact our Incident Response team.
