Check Point root flaw: which Jumbo take fixes it, how to check

Check Point has confirmed that attackers used a local privilege escalation flaw in Gaia OS to take root on customer gateways, after getting in through the Mobile Access portal with PHP2Shell. The flaw is CVE-2026-123039, rated 7.8, and the company says it saw the exploit used against a couple of dozen customers.

The mechanism is as plain as these get. Gaia hands its dynamic and extended CLI to a root-owned process called dynamic_server, which waits on a local IPC socket at /tmp/dynamic_socket. On affected builds that socket is created world-writable at 0777, nothing authenticates the process connecting to it, and the daemon runs whatever command string arrives. One write to the socket by any authenticated local user, and the command runs as root.

That 7.8 is the number to argue with. A local flaw that needs code execution on the appliance first looks like a second-week ticket. In this campaign it was the hinge. Check Point Research traces scanning and exploitation from October 30, using PHP2Shell, CVE-2026-109618 and CVE-2026-109619, against unpatched Mobile Access portals, with the DynamicCLI flaw as the step from a portal service account to root. From there came webshells as zz*.tpl files in the portal's template directory, the TSGA implant running as /tmp/CPconfigdaemon and relaunching itself as slot_CPconfigdaemon for persistence, and its embedded TSProxy library dropped to /lib/libcpfwcommon.so. Attackers then ran the gogo scanner, reached a VMware ESXi host over SSH with the vpxuser account, and executed the destroy_v6 wiper, which by default tries to zero each file first, then delete it, with a fast mode that skips the overwrite.

The fix for the first half of that chain had been out since October 23, a week before the first wave.

Which build is fixed

Check Point names the fixed Jumbo Hotfix Accumulator takes directly: R82.20 from Take 14, R82.10 from Take 52, R82 from Take 132, R81.20 from Take 174. The advisory lists R81 and R81.10 as affected as well, both marked end of support, and names no fixed take for either. Spark Firewalls and Smart-1 Cloud are not affected.

One discrepancy to resolve on your own estate before you sign anything off. Check Point's CVE record, published through NVD, lists systems as affected at R82.10 Take 50 or below, R82.20 Take 10 or below, R82 Take 130 or below and R81.20 Take 173 or below. Read the other way, that puts the first fixed take at 51 for R82.10, 11 for R82.20 and 131 for R82, one take earlier than the SK article for two of them and three takes earlier for R82.20. For R81.20 the two agree on Take 174. Both datasets are Check Point's own, and NVD has not enriched or scored the entry yet, so this is the vendor disagreeing with itself rather than a third party. Take the SK article as the bar and check your installed take.

How to check whether the socket was used

Every command the vulnerable daemon is handed goes into one log, /var/log/dynamicCli.log, which makes the exposure question answerable tonight.

• Look for commands that did not come through the expected Clish wrapper: grep "Received =" /var/log/dynamicCli.log | grep -vF "CPprofile.sh >> /dev/null; export SP_DISTRIBUTE=0; set -o noglob;". Anything left over may have run as root through the socket.
• Look for the system() sink, which Check Point says is uncommon or absent in normal traffic: grep -F "Received = #return_value#" /var/log/dynamicCli.log.
• Look for the commands an attacker reaches for, which is the advisory's third check: grep -EI "Received =.*( id;| whoami| /etc/shadow| ncat| nc -| /dev/tcp| curl | wget | base64| useradd| authorized_keys)" /var/log/dynamicCli.log.
• Check whether the daemon is running at all, in Expert mode: ps auxw | grep -v grep | grep 'dynamic_server'.
• Confirm a patched box with the socket itself: ls -l /tmp/dynamic_socket should come back srw-rw---- root config, mode 0660, not the world-writable 0777.
• On a patched box the log also records blocked calls, naming the unauthorized uid. An unexpected uid there, 99 for nobody being the advisory's example, means an escalation attempt was made and stopped, so it is an attack indicator rather than a clean bill of health. Check Point suggests correlating bursts of them with portal and authentication logs to find the source.

Alongside those, Check Point's indicator list is worth running past the gateway and the hosts behind it: PHP session files holding the string upload_progress_pwn, a binary masquerading as a Check Point component with a CPconfigdaemon-style name, scanner or wiper tooling under /tmp, a note referring to Dream Annexation with no payment demand, and gaps in firewall traffic logs after the logging daemon crashed. TSGA tampers with those logs, so a gap is a finding rather than a glitch. Check Point adds that no match does not clear a box.

What IT teams should do

• Install the November Jumbo Hotfix on Management Servers and Security Gateways, internet-facing Mobile Access deployments first. Check Point says it carries the PHP2Shell and Node2Shell fixes, CVE-2026-111497 being the Brotli one, and the DynamicCLI fix arrives with the takes named above, so check the take you land on rather than assuming one bundle covers everything.
• Where the hotfix has to wait, stop dynamic_server and keep it from restarting with dbset process:dynamic_server then dbset :save. That breaks the Dynamic CLI commands in sk144112, and dbset process:dynamic_server t followed by dbset :save puts it back.
• Run the two log greps on every affected gateway before the logs roll, not only on the ones facing the internet.
• Treat a hit as an appliance compromise rather than a single flaw. The campaign ended on an ESXi host, so check SSH authentication for vpxuser and look at what the gateway could reach.
• Do not wait for a KEV listing to prioritize this. As of CISA's catalogue update of November 10, CVE-2026-123039 is not in the Known Exploited Vulnerabilities list, and the exploitation is confirmed by the vendor either way.

On attribution, Check Point is careful, and so is this story. TSGA and TSProxy are variants of PhiliKit, which ESET has associated with the China-nexus group UNC5221. The destruction, the focus on Israeli organizations in the first wave and the Hebrew note do not, in Check Point's words, appear to fully align with that profile, and it says the evidence does not support a high-confidence assessment, listing an initial access broker and a false flag among the plausible readings.