Check Point Vulnerability CVE-2026-123039 (DynamicCLI Root Escalation)

CVE-2026-123039 is a vulnerability in DynamicCLI on Check Point Gaia OS. The root-level dynamic_server daemon listens on the world-writable /tmp/dynamic_socket and does not authenticate connecting processes, so a low-privilege local user can run commands as root (CVSS 7.8). Check Point has confirmed exploitation against a couple of dozen customers, and CISA added it to the KEV catalog on November 13, 2026. Organizations running Check Point firewalls or management servers should check their version and Jumbo Hotfix take, apply the fix if affected, and look for signs of compromise.

This article draws on Check Point's sk1000362, CISA's KEV alert and BleepingComputer's report to lay out the affected range, how to check, what to do per environment, mitigations while you cannot patch, and how to look for signs of compromise. Figures and dates are limited to what primary sources confirm; anything not published is stated as such.

- What: Gaia's dynamic_server listens on the world-writable /tmp/dynamic_socket without authenticating the caller, so a low-privilege local process can run commands as root. CVSS 7.8. Check Point confirmed exploitation against a couple of dozen customers, and CISA added it to KEV on November 13, 2026
- Who: Check Point Force Firewalls, Management and Log Servers, Multi-Domain Security Management / Log Server and Maestro Orchestrator on R82.20 / R82.10 / R82 / R81.20 / R81.10 / R81. Spark Firewalls and Smart-1 Cloud are not affected
- What to do: Update the Jumbo Hotfix Accumulator to Take 14 or later on R82.20, Take 52 or later on R82.10, Take 132 or later on R82, and Take 174 or later on R81.20. Until then, mitigate by stopping dynamic_server and check /var/log/dynamicCli.log for signs of compromise

The table lists the affected versions in sk1000362 and the Jumbo Hotfix Accumulator take that contains the fix. If your take is equal to or higher than the number shown, the fix is in place.

Affected products are Force Firewalls, Management and Log Servers, Multi-Domain Security Management and Multi-Domain Log Server, and Maestro Orchestrator. Spark Firewalls and Smart-1 Cloud are listed as not affected.

Gaia is the dedicated OS that runs Check Point products, and a mechanism called DynamicCLI accepts configuration commands from other processes. The receiver is a daemon called dynamic_server, which runs as root and uses a local socket (a file-like entry point for communication between processes) at /tmp/dynamic_socket.

The problem is that this entry point is created writable by every user (srwxrwxrwx, i.e. 0777 in the vulnerable state) and does not check who is connecting. Anyone who can run a low-privilege process on the device can write a command to the socket and have it run as root. CISA's KEV entry names the weakness Incorrect Permission Assignment for Critical Resource.

"Local" can sound like something only a person at the keyboard could do. In practice it is the next step once an attacker has run low-privilege code on the device through another vulnerability or impersonation. The entry point is elsewhere; this flaw does the job of raising privileges to root afterward.

According to BleepingComputer, attacks have been seen since late October. The attackers first got into the Mobile Access portal (reportedly through vulnerabilities called PHP2Shell), then gained root with this flaw, dropped web shells and installed the TSGA backdoor and TSProxy malware. They then moved from the gateway to a VMware ESXi host and deployed a destructive wiper (malware that erases data). A gateway where an attacker holds root can also reach the traffic and credentials passing through it, so this should not be dismissed as a standalone bug.

Check Point says it has observed exploitation against a couple of dozen customers. The affected organizations and a detailed breakdown of the damage have not been published.

Checking takes three steps. First look at the Gaia version and the Jumbo Hotfix take, then at whether dynamic_server is running, and finally at the socket permissions to tell whether the fix is in. Run the commands below in the Expert mode shell.

The version and take appear in the Jumbo Hotfix Accumulator entry of the cpinfo -y all output. The display differs by environment, so if you are unsure, the applied updates shown in the Gaia portal's update screen (CPUSE) are a more reliable source. If your take is below the number in the table, an update is needed.

After the fix the socket permissions become srw-rw---- root config (0660), so only that group can write to it. If it is still srwxrwxrwx (0777), the fix is not in place. After the fix, connections from unauthorized users are rejected and logged. The following command shows them; a rejected connection from a UID such as 99 (nobody) indicates that an escalation attempt was blocked after the fix.

If entries appear, compare the time against the portal, web and authentication logs. Even a failed attempt suggests that low-privilege code ran on the device, which means another entry point may exist.

Update the Jumbo Hotfix Accumulator to Take 14 or later on R82.20, Take 52 or later on R82.10, and Take 132 or later on R82. The procedure is the usual maintenance one, through CPUSE in the Gaia portal. On clusters, update one member at a time and confirm failover before moving on. After updating, check the socket permissions (0660) as described above.

Update the Jumbo Hotfix Accumulator to Take 174 or later. The procedure is the same as on R82.x. A fix is available even if you remain on R81.20. After updating, check the socket permissions and review the logs from before the update for traces.

sk1000362 marks these two versions as EOS (end of support) and lists no fixed take. The realistic option is to plan an upgrade to a supported version (R81.20 or later). Until that is in place, apply the dynamic_server mitigation described below and check for signs of compromise. Internet-facing gateways should be given higher priority.

Multi-Domain Security Management, Multi-Domain Log Server and Maestro Orchestrator are also affected. Because one Multi-Domain server manages several domains, losing root on one has a wider blast radius. The take to apply follows the per-version numbers in the table above. Maestro may need updates per component, so check the procedure in sk1000362 and Check Point's documentation.

If maintenance and operations are outsourced, ask the provider in writing (e.g. by email) for three things: (1) the product, version and Jumbo Hotfix take of your devices, (2) the planned date of application (or the date if already applied), and (3) the result of the dynamicCli.log check. While the provider is still checking, decide whether to ask them to stop dynamic_server in the meantime, weighing the impact on your operations.

For cases where the Jumbo Hotfix cannot be applied right away, Check Point describes a temporary measure: stop the dynamic_server process and configure it not to restart. The command uses dbset and is saved with dbset :save. Confirm the value to specify when stopping it in sk1000362 (this article does not state it).

As a side effect, the Dynamic CLI commands listed in sk144112 will fail, so first check whether you use them in automation or operations. To revert, run dbset process:dynamic_server t followed by dbset :save. This mitigation is not a substitute for the patch, and it does not undo an intrusion that has already happened, so always do the check in the next section.

As a general measure, also review whether management interfaces or the Mobile Access portal are needlessly exposed to the internet. In the reported attacks, an exposed portal is said to have been the first foothold. Where exposure is necessary, restrict source addresses and strengthen log monitoring.

Exploitation is reported from late October, so even after patching, check whether the device was already compromised before the update. Check Point describes three searches of the traces left in /var/log/dynamicCli.log.

The first finds commands that did not go through the Clish wrapper used by legitimate operations. The second finds execution through the system() sink, which is uncommon in normal traffic. The third finds traces of commands often used in attacks, such as id, whoami, /etc/shadow, nc, curl, wget, base64, useradd and authorized_keys. Check Point asks that any match be investigated as possible root command execution through the socket. Not every match is an attack, so judge using timestamps, surrounding logs and your administrators' work records.

If you find traces, respond in this order.

- Isolate: Disconnect the device from the network or restrict its traffic as far as practical. Consult a specialist before powering it off so that logs and memory needed for the investigation are not lost
- Preserve records: Copy dynamicCli.log and related logs elsewhere. Remember that an attacker may have deleted logs
- Change credentials: Change administrator passwords, VPN certificates and keys, and credentials of linked accounts stored on or passing through the device. Treat information on a device where an attacker had root as read
- Check surrounding systems: Reports describe lateral movement to ESXi and wiper deployment, so check virtualization hosts, backups and servers on the same segment for anomalies, and confirm that backups are protected separately
- Consult specialists: Contact an incident response specialist or Check Point support. If personal or customer data may be affected, consider whether you have legal reporting obligations

CISA's KEV alert says the addition is based on evidence of active exploitation and refers federal agencies to BOD 26-04 for prompt remediation. The KEV catalog sets the federal remediation due date at November 16, 2026. Organizations outside the federal government are likewise advised to treat it with the same priority.

- List your Check Point devices (gateways, management servers, log servers, Multi-Domain, Maestro) and check their versions
- Check each device's Jumbo Hotfix take and compare it with the fixed takes in the table
- Run ls -l /tmp/dynamic_socket and confirm the permissions are 0660
- For unfixed devices, set a date to apply the Jumbo Hotfix. If you cannot patch immediately, mitigate by stopping dynamic_server (first check the impact on sk144112 commands)
- If you run R81.10 / R81, plan an upgrade to a supported version
- In dynamicCli.log, search for rejected-connection entries and run the three compromise searches (check whether logs reach back to late October)
- Review whether the Mobile Access portal and management interfaces are needlessly exposed to the internet
- If you outsource operations, get the status in writing
- Decide now who to contact if traces are found (internal owner, provider, specialist)

- Vulnerability digest for November 14
- SonicWall CVE-2026-19868 (SSLVPN SAML and MFA bypass): how to check and fix
- UTM and firewall costs and selection for small businesses

- Check Point sk1000362 (CVE-2026-123039): https://support.checkpoint.com/results/sk/sk1000362
- CISA, "CISA Adds Two Known Exploited Vulnerabilities to Catalog" (November 13, 2026): https://www.cisa.gov/news-events/alerts/2026/11/13/cisa-adds-two-known-exploited-vulnerabilities-catalog
- BleepingComputer, "Check Point patches zero-day that lets hackers get root access": https://www.bleepingcomputer.com/news/security/check-point-patches-zero-day-that-lets-hackers-get-root-access/
- NVD CVE-2026-123039: https://nvd.nist.gov/vuln/detail/CVE-2026-123039