Check Point CVE-2026-123039 Exploited for Root on Gaia

Check Point CVE-2026-123039 is a local privilege escalation flaw in Gaia OS that is being exploited now. The DynamicCLI daemon runs as root and accepts unauthenticated commands on a world-writable socket, so any local user on a firewall or management server can become root. CISA added it to the KEV catalog on 13 November 2026 with a 16 November deadline. Install the fixed Jumbo Hotfix take today, or stop the daemon until you can, and review /var/log/dynamicCli.log for signs of abuse.

What happened

Check Point published sk1000362 for CVE-2026-123039. The advisory was created on 8 November and last updated on 12 November, and the CVE record was published the same day. Check Point says it has seen active exploitation against a couple dozen customers.

CISA added the flaw to its Known Exploited Vulnerabilities catalog on 13 November 2026. The due date for federal agencies is 16 November, three days later. The entry is flagged for CISA's forensic triage requirements, which means agencies are expected to look for compromise as well as patch. Known ransomware use is listed as unknown.

The CVSS 3.1 score is 7.8 (High), with vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. The weaknesses are CWE-862 (missing authorization) and CWE-732 (incorrect permission assignment for a critical resource).

Who is affected

Per sk1000362, the affected products are:

Quantum Force firewalls (security gateways)
Management and log servers
Multi-Domain Security Management and Multi-Domain Log Server
Maestro Orchestrator

Spark firewalls and Smart-1 Cloud are not affected. The CISA entry also lists Scalable Platforms.

Affected Gaia releases are R82.20, R82.10, R82, R81.20, R81.10 and R81. R81.10 and R81 are end of support, and the advisory lists no fix for them.

Technical analysis of CVE-2026-123039

The dynamic_server process backs Gaia's Dynamic CLI. It runs as root and listens on the local socket /tmp/dynamic_socket. On affected builds that socket is world-writable (mode 0777), the daemon does not check who is connecting, and it runs whatever command string it receives as root. A process running under any local account can send one request and get root.

On Linux, connecting to a Unix stream socket needs only write permission on the socket file, so a 0777 mode is effectively an open door. Our explainer on what a Unix domain socket is and how its permissions work covers why the file mode is the whole access control here.

The attacker needs code execution on the appliance first. That could be a low-privilege administrator account, a stolen credential, or a separate flaw in a web-facing component. Check Point has not published how the attackers it observed got their initial foothold. That gap is why a "local" bug still matters on a perimeter device: see why local privilege escalation on firewalls is urgent.

The fix changes the socket to mode 0660, owned by root and the config group, and blocks and logs unauthenticated Dynamic CLI calls.

What to do now

Patch to a fixed Jumbo Hotfix take

Install at least the following Jumbo Hotfix Accumulator take on every gateway, cluster member and management server:

R82.20: Take 14 or later
R82.10: Take 52 or later
R82: Take 132 or later
R81.20: Take 174 or later

R81.10 and R81 have no listed fix. Plan the upgrade to a supported release now and apply the mitigation below in the meantime.

Stop the daemon if you cannot patch yet

sk1000362 describes stopping dynamic_server and preventing it from restarting through the Gaia database (dbset process:dynamic_server followed by dbset :save). Take the exact value from the SK before running it. Dynamic CLI commands listed in sk144112 fail while the process is stopped. To turn it back on after patching, the SK gives dbset process:dynamic_server t and then dbset :save.

Confirm the state in Expert mode. No output means the process is stopped:

ps auxw | grep -v grep | grep 'dynamic_server'

Hunt for exploitation

Review /var/log/dynamicCli.log on every firewall and cluster member. Check Point's guidance:

Look for Received = entries that lack the standard Clish wrapper (CPprofile.sh >> /dev/null; export SP_DISTRIBUTE=0; set -o noglob;).
Search for Received = #return_value#, which is rare in legitimate traffic.
Search for commands seen in exploitation, such as id, whoami, /etc/shadow, nc, curl, wget, base64, useradd, authorized_keys and /dev/tcp.

If you find hits, treat the appliance as compromised. Check for new local users and added SSH keys, then rotate credentials stored on the box. Our guide to auditing appliance configuration changes after an exploit covers that review.

Verify the fix

After patching, check the socket mode:

ls -l /tmp/dynamic_socket

It should show srw-rw---- owned by root and config (0660), not srwxrwxrwx (0777). The patched daemon logs Rejected connection from unauthorized uid when it blocks a caller. An unexpected UID in those lines means someone tried to escalate after the fix. Correlate bursts of rejections with portal, web and authentication logs to find the source.

To check the rest of your Linux estate for the same mistake, see how to find world-writable sockets on Linux.

What to watch next

Initial access. The advisory describes the root step but not how attackers got local code execution. If Check Point or CISA names the first-stage flaw, patch that too and widen the hunt.
Version discrepancy. The CVE record lists R82.20 as affected through Take 10, while sk1000362 lists Take 14 as the first fixed take. Go by the SK and install Take 14 or later.
End-of-support releases. R81 and R81.10 sites have only the mitigation. Expect pressure from auditors and insurers to show an upgrade date.

This is the second Check Point issue this autumn that turns a foothold into control of the appliance. The September Check Point VPN flaws CVE-2026-85102 and CVE-2026-85103 were remote. Keep both on your appliance patch tracker.