Check Point Management Servers Face Script-Upload Attacks
Check Point reports customer attacks through an unauthenticated management-server flaw. Match Jumbo Hotfix takes, restrict TCP/19009 and inspect CPM logs.

Check Point management servers are being attacked through an unauthenticated path-traversal and file-upload flaw that lets an intruder run scripts on the server. In its September 22 advisory, the company says it knows of “a handful of customers who have been attacked.” The affected roles include security-management, logging and event systems, so involve the owners of the management and logging servers alongside the firewall policy team.
On September 22, CISA listed CVE-2026-93616 as exploited; federal agencies faced a September 25 remediation deadline. That deadline has passed; the vendor’s fixed takes and log checks give operators a concrete way to address the exposure now. Check Point says Smart-1 Cloud already has the fix and lists Check Point Firewall Appliances and Spark Firewall as unaffected by this flaw.
A file path reaches the manager
The Check Point-authored CVE record describes directory traversal and file upload allowing an unauthenticated attacker to upload and execute arbitrary scripts on a Management Server. Path traversal lets a supplied file path escape its intended directory; here the consequence is code running on a system that administers security infrastructure. The record rates the flaw 9.8 under CVSS v3.1, with network access and no required privileges or user interaction.
Check Point names five affected roles: Security Management Server, Multi-Domain Security Management Server, Log Server, Multi-Domain Log Server and SmartEvent. Its affected release list includes R82.20 before the security hotfix, R82.10 through Jumbo Hotfix Take 44, R82 through Take 126, R81.20 through Take 166, and end-of-support R81.10 through Take 190. The older R80 family and R81 are also listed as affected and end of support. Inventory those roles and compare the installed branch and take on each server with the vendor’s fixed-release list; a gateway’s version cannot stand in for the manager’s.
The CPM logs offer two leads
Check Point gives operators two indications to search for on affected management, domain, log and SmartEvent servers. In "$MDS_FWDIR"/log/cpm.elg*, one is a loginRequest=LoginRequest with an authenticationInfo=AuthenticationInfoBase username longer than 1,000 characters. Check Point directs operators to correlate that login time with fwm or mds core dumps in /var/log/dump/usermode/. A matching dump at the same time points to a potential exploitation attempt. Preserve the log and dump for investigation before cleaning up.
The other lead is an error from upgrade.base.ReflectionUtils reading Failed to load allResourceFiles map from. Inspect the path in that error for traversal sequences such as ../. Check Point says a match can mean a potential attempt against this CVE. The vendor’s example places the traversal inside an upgrade-tools path; the observable is the error together with its suspicious path. These are triage leads, so investigate matches in context and preserve the related timestamps and host identity.
Patch the server and narrow access
Check Point provides an R82.20 Security Hotfix and says the fix is included from Jumbo Hotfix Take 45 for R82.10, Take 127 for R82, Take 170 for R81.20 and Take 192 for R81.10. Use the vendor’s current advisory to select the hotfix for each branch, then verify the installed take or hotfix on the actual management or log server. The advisory lists R81.20 Takes 166 and below as affected but names Take 170 as its fixed starting point; for an intermediate take, move to the listed fixed take instead of assuming it carries the repair. Check Point explicitly says LivePatch Takes 28 and 29 do not fix this issue, and the nature of the fix rules out a LivePatch for it.
Restrict management-server access behind a Security Gateway or Check Point Firewall. In particular, permit TCP/19009 only from trusted IP addresses. If implied rules are in use, Check Point says to limit SmartConsole’s Manage & Settings > Permissions & Administrators > Trusted Clients to trusted internal IPs so the implied access rule follows that scope. Confirm from the allowed administration network that the legitimate client still reaches the management service, then test from an untrusted network that TCP/19009 is blocked.
Confirm the manager’s fixed state
Management and logging owners have two separate jobs: install a vendor-listed fixed hotfix or take on each affected server, and limit TCP/19009 to trusted clients. Search the server’s cpm.elg* for the oversized login username with a same-time fwm or mds dump and for the ReflectionUtils path error with ../; investigate matches as possible attempts. A successful patch check establishes the installed fix, while the log and dump review addresses activity that may already have reached the service. Verify the access rule from both an allowed and an untrusted network after the change.