Check Point CVE-2026-93616: Patch Management Servers and Check for Compromise
Check Point has disclosed CVE-2026-93616, a critical vulnerability affecting several on-premises security-management products. The vendor says an unauthenticated attacker can use directory traversal and file upload weaknesses to place and execute arbitrary scripts on a management server. Check Point also says the vulnerability is being exploited in the wild and that it is aware of a handful of attacked customers.[1]
For organizations that operate Check Point infrastructure, this is not a routine patch-when-convenient issue. The affected systems sit in a privileged management plane. A compromise could undermine the systems used to administer security policy, collect logs, and investigate other incidents.
What CVE-2026-93616 affects
Check Point assigns the issue a CVSS score of 9.8. Its advisory identifies these affected product families:
- Security Management Server
- Multi-Domain Security Management Server
- Log Server
- Multi-Domain Log Server
- SmartEvent
The advisory says Smart-1 Cloud already has the fix applied. It also says Check Point Firewall Appliances and Check Point Spark Firewall are not affected by this specific vulnerability.[1]
Affected version boundaries require careful reading. Check Point lists R82.20, R82.10 Jumbo Hotfix Take 44 or lower, R82 Jumbo Hotfix Take 126 or lower, R81.20 Jumbo Hotfix Take 166 or lower, R81.10 Jumbo Hotfix Take 190 or lower, and several end-of-support R80/R81 branches. Administrators should compare the exact installed product, release, and Jumbo Hotfix Take against the current vendor advisory rather than relying on a major-version label alone.
CISA added CVE-2026-93616 to its Known Exploited Vulnerabilities catalog on September 22, 2026.[2] CISA assigns a September 25 remediation date to covered federal agencies under its directive. That date is not a universal private-sector deadline, but the confirmed exploitation and management-plane exposure justify urgent business triage.
Why the management plane changes the response
A security management server is more sensitive than an ordinary application server. It may hold administrative configuration, security policy, logs, trusted-client definitions, and connections to enforcement infrastructure. Even when the server does not directly process public application traffic, an exposed or overly permissive management interface can create a path to highly privileged systems.
The practical lesson is to treat this as both a vulnerability-management task and a possible incident-response task. Installing a hotfix closes the known vulnerability; it does not establish that a previously exposed system was never accessed.
For small and midsized organizations, the best response is an inventory-first workflow: identify whether the products exist, determine who manages them, establish their exposure, restrict access, preserve useful logs, apply the vendor fix, and then verify both patch state and signs of attempted exploitation.
Immediate action checklist
1. Identify every relevant Check Point server
Inventory Security Management, Multi-Domain Management, Log, Multi-Domain Log, and SmartEvent systems. Record the installed release, Jumbo Hotfix Take, hosting location, management IPs, internet reachability, and responsible administrator.
Do not assume a firewall-appliance inventory is enough. The affected management and logging servers may be virtual machines or separate appliances maintained outside the normal network-device list.
2. Restrict management access now
Check Point recommends placing management servers behind a Security Gateway and limiting access to TCP port 19009 to trusted IP addresses. It also advises reviewing SmartConsole trusted-client settings so that access is limited to trusted internal sources.[1]
Treat this as a temporary risk-reduction measure, not a substitute for the fix. Before changing access rules, confirm remote-administration requirements and preserve an approved recovery path so an incorrect rule does not lock out legitimate administrators.
3. Apply the supported fix for the exact release
Check Point states that a LivePatch is not available for this issue and specifically warns that LivePatch Take 28/29 does not address it. The vendor lists an R82.20 security hotfix and says the fix is included in these Jumbo Hotfix Accumulator levels:
- R82.10 starting with Take 45
- R82 starting with Take 127
- R81.20 starting with Take 170
- R81.10 starting with Take 192
Use the current advisory and Check Point support guidance for the exact upgrade path. Back up the management system and configuration, review cluster or multi-domain dependencies, test where practical, and schedule enough time to verify services after installation. End-of-support releases should be moved to a supported branch rather than treated as permanently resolved by an isolated emergency change.
4. Check the vendor’s indicators of compromise
The Check Point advisory provides Expert-mode commands for reviewing management logs for unusually long usernames, related core dumps, and directory-traversal strings in upgrade-related error messages.[1] Run the current vendor-provided checks on each affected management, logging, and SmartEvent server.
A matching indicator may show an attempted exploit and should trigger investigation. Preserve relevant logs, timestamps, command output, and system images before cleanup. If compromise is suspected, avoid relying only on the potentially affected management server for evidence or containment decisions.
5. Validate remediation and watch for recurrence
After patching, confirm the installed Take or hotfix on every node, verify management and logging functions, retest allowed administration paths, and confirm that TCP/19009 is not exposed beyond intended trusted sources. Monitor authentication, process, file, and policy-change activity for anomalies.
Document the result: systems reviewed, exposure found, fixes installed, indicators checked, exceptions approved, and follow-up owners. This makes the response auditable and prevents a secondary node or disaster-recovery instance from being missed.
If signs of exploitation appear
Move from patch management to incident response. Isolate affected management systems carefully, preserve evidence, and determine whether unauthorized scripts or policy changes occurred. Review administrative accounts, trusted clients, recent configuration changes, connected gateways, log integrity, and credentials or secrets available to the server.
Credential rotation and configuration validation may be necessary, but sequence them with evidence preservation and containment. Restoring a management server without understanding what changed can erase useful evidence or reintroduce a compromised configuration.
A practical Reliant System perspective
The highest-value operational improvement is separating security administration from ordinary user and server traffic. Management interfaces should be reachable only from controlled administrative networks or hardened access paths, with named ownership, monitored authentication, tested backups, and a documented emergency-access procedure.
Organizations that need help identifying exposure, validating segmentation, or coordinating patch and incident-response work can review Reliant System’s information security audit services and network design services. If a Check Point management server may have been exposed or compromised, contact Reliant System for a scoped technical review.