Check Point Gateways Were Breached Through PHP2Shell, Then Rooted Through a World-Writable Socket. Install the Jumbo Take and Read One Log File Today.
If you run a Check Point Security Gateway, Management Server, Multi-Domain server or Maestro Orchestrator, install the fixed Jumbo Hotfix take today: R82.20 Take 14, R82.10 Take 52, R82 Take 132 or R81.20 Take 174, or later. R81.10 and R81 are out of support and get no fix. If Mobile Access is enabled, assume the portal was tried after October 30 and check two places: the DynamicCLI log and the portal's templates directory. Check Point says it saw this flaw exploited against "a couple dozen customers."
What is confirmed
Two Check Point documents, both read in full on November 13.
The new flaw is CVE-2026-123039, and it is a privilege escalation, not a way in. Check Point's advisory sk1000362 is titled "Local privilege escalation to root in the DynamicCLI process via local world-writable control socket." A root process called dynamic_server listens on /tmp/dynamic_socket. On affected builds the socket is world-writable (0777), it does not authenticate whoever connects, and the daemon runs the command strings it receives as root. The attacker needs to be running code on the appliance already, or to hold a local account. CVSS 7.8. The advisory was created November 8 and last modified November 12.
Affected: Check Point Force Firewalls (Security Gateways), Management and Log Servers, Multi-Domain Security Management and Multi-Domain Log Server, and Maestro Orchestrator. Not affected: Spark Firewalls and Smart-1 Cloud.
The way in was PHP2Shell. Check Point Research's report, published November 12, says: "Beginning on 30 October 2026, an attacker executed scanning and exploitation activity against organizations with unpatched Check Point Security Gateways, using Mobile Access portals with PHP2Shell as initial access followed by CVE-2026-123039." It ties PHP2Shell to the same two PHP bugs we have covered since October 21, CVE-2026-109618 and CVE-2026-109619, and says the first activity came "approximately one week after a security fix became available."
So the two halves the press reported separately are one chain in Check Point's own telling. BleepingComputer led with the zero-day; The Hacker News led with PHP2Shell. The research report connects them: PHP2Shell gave the attacker the portal's service account, and the socket turned that into root.
What happened next, per the report: PHP webshells written into the portal's templates directory as zz-prefixed .tpl files, a backdoor Check Point calls TSGA launched from /tmp/CPconfigdaemon and relaunched as slot_CPconfigdaemon, an injected library called TSProxy written to /lib/libcpfwcommon.so, the open-source gogo scanner run from the gateway against the internal network, SSH to a VMware ESXi host as the vpxuser service account, and a wiper called destroy_v6 that zero-fills and deletes files and leaves a note called DREAM_ANNEXATION.txt.
Two waves. October 30 targeted Israeli organizations, and some of them were wiped. November 2 hit organizations in several countries and sectors, and Check Point found no destruction in that wave.
What is not known
Who did it. Check Point says TSGA and TSProxy are modified variants of PhiliKit, a toolkit ESET associated with the China-nexus group UNC5221 after Ivanti attacks, and that the attacker's servers sat on LightNode VPS hosting with scanning concentrated between 00:00 and 09:00 UTC. It also says the wiper, the Israel focus and the note do not fit that group, and concludes the evidence "does not allow us to assess with high confidence the true nature of this operation." The options it lists: the same actor ran everything, sold the access on, or staged a false flag. We are not picking one.
How many gateways. "A couple dozen customers" is the only number Check Point gives, and it covers the privilege escalation, not every portal that was scanned.
Whether wave 2 got root. The report describes the root escalation in the investigated intrusion. It does not say how many wave-2 targets got past the portal.
Which Check Point fix covered PHP2Shell on the portal. The report says a fix existed about a week before October 30. We did not find a Check Point advisory for PHP2Shell on gateways in the sources we read, so we cannot name the take. Ask Check Point support, or confirm your Jumbo take is newer than late October.
CISA's view. CVE-2026-123039 is not in the KEV catalog we downloaded today (catalog version 2026.11.10, released November 10). The two PHP CVEs are: CISA added both on Monday, October 26, with a federal due date of Thursday, October 29.
What to do
Patch. R82.20 Jumbo Hotfix Take 14 or later, R82.10 Take 52, R82 Take 132, R81.20 Take 174. On R81.10 or R81, upgrade: there is no fix for those versions.
If you cannot patch today, sk1000362 says to stop dynamic_server and keep it from restarting. Follow the advisory's steps exactly as written. It warns that this breaks the Dynamic CLI commands listed in sk144112. We noticed the example command in the advisory leaves out the disable value, so confirm it with Check Point before running it rather than guessing.
Verify the fix took. In Expert mode, list /tmp/dynamic_socket. Patched, it reads as owned by root, group config, mode 0660. Unpatched, it shows as world-writable.
Hunt the escalation. The daemon logs every command it receives to /var/log/dynamicCli.log. Legitimate requests use Check Point's Clish wrapper, so any "Received =" line without it needs a look. Check Point also flags the system() path, which appears as "Received = #return_value#", and common attacker commands such as id, whoami, /etc/shadow, nc, curl, wget, base64, useradd and authorized_keys. After patching, a burst of "Rejected connection from unauthorized uid" lines, especially uid 99 (nobody), is someone still trying. Line those up against portal and login logs.
Hunt the foothold. Per the research report: session files containing upload_progress_pwn under /opt/CPcvpn-R81.20/tmp/, hundreds of Apache or PHP segmentation faults around October 30, zz-prefixed .tpl files or challenge_render.tpl in the portal templates, /tmp/.up.tpl, /tmp/CPconfigdaemon, /tmp/.bd.log, /lib/libcpfwcommon.so, and a process named slot_CPconfigdaemon. Check Point also says TSGA and PhiliKit talk over TCP port 11072 and the Unix socket /tmp/.p_sock, and that TSGA listens on all interfaces.
Treat a hit as a network compromise, not an appliance problem. The attacker went from the gateway to ESXi with a service account. If you find any of the above, rotate the vpxuser credentials and anything else the gateway could reach, and check the ESXi hosts behind it. Patching the gateway does not remove a backdoor already running on it.
Block the published indicators (below). They are a supplement to the patch, not a substitute for it.
The lesson from our October advice
On October 21 we told readers to patch PHP today. On a server you manage, that means your package manager. On an appliance, the PHP inside belongs to the vendor, and the only way to update it is the vendor's hotfix. Check Point's portal ran PHP under Apache, which is the setup PHP's own advisory called highest risk. If you patched every PHP server you own in October and stopped there, your firewall's VPN portal was not on that list.
Indicators, and what we did with them
Check Point Research published 8 SHA-256 hashes and 2 IP addresses. We screened each before it went anywhere near a blocklist, the same way we screened the Zscaler PHP2Shell table on October 28.
The two IPs, 130.94.19.204 and 130.94.19.168, resolve to LIGHT NODE LIMITED (AS154177) via ARIN RDAP, a rentable VPS provider. The attacker rents those boxes, and the lease eventually goes to someone else. We publish them at confidence 60: in the default feed, below our own edge shield's blocking floor, so our enforcement stops before an innocent tenant inherits the address.
Six hashes are the attacker's own tools, at confidence 90: the .tpl webshell (edb3e92e…da2b3), slot_CPconfigdaemon (4171b521…a2ec8), CPconfigdaemon (d7549671…a0c63), the destroy_v6 wiper (c7d94773…03237, which Check Point's table spells destory_v6), and the two PhiliKit reference samples, philistine (ee16e169…a39d7) and libdssafe.so (fb1a6235…654da).
The wiper note (0522937c…a96f7) is in at 80. Check Point says the note carries a timestamp, so other copies may hash differently. Hunt for the filename too.
The gogo scanner (3b51080a…2db90) is in at 50. gogo is a public scanner that penetration testers also use, so a match on that hash is a lead to investigate, not proof of compromise.
All ten are in our feed under the source manual-batch-checkpoint-philikit-2026-11 with Check Point's report as the reference, and every record was read back from the index after it was written. Full hashes are in Check Point's report and in our records.
A note on timing, because it is easy to misread: an automated job of ours that collects indicators from vendor blogs picked these up on November 12 at 14:17 UTC, about twenty minutes after Check Point published. That is us copying Check Point's work, not seeing the attack ourselves. Today's records add attribution, screening and confidence to the same values.
What our own instruments can and cannot see
We run no Check Point products, so we had nothing to patch.
We checked our edge for the attack anyway. Since October 14, nothing requested common Check Point portal paths (sslvpn, clients/MyCRL, Login/Login, CSHELL) from us: 0 of 392,706 edge-blocked requests, 0 of 58,802 decoy hits, 0 of 614 requests that reached our origin. Since October 1, neither of the two LightNode IPs touched us (0 of 403,315 blocks, 70,684 decoy hits, 1,757 origin requests), and nothing from AS154177 hit our edge blocks or decoys.
Read those zeros with care. Our sites are not Check Point portals, so an attacker hunting gateways has no reason to visit us. And the escalation itself, a local process writing to a local socket on the appliance, never crosses the internet. No web-facing instrument anywhere could have seen step 2. One public proof-of-concept repository for CVE-2026-123039 appeared on GitHub on November 13; we have not vetted it and do not recommend running it.
Sources
Check Point, sk1000362, "Local privilege escalation to root in the DynamicCLI process via local world-writable control socket," created November 8, 2026, modified November 12 (support.checkpoint.com). Check Point Research, "PHP2Shell Exploitation on Check Point Gateway," November 12, 2026 (research.checkpoint.com). CISA Known Exploited Vulnerabilities catalog, JSON feed, version 2026.11.10, downloaded November 13. ARIN RDAP for 130.94.19.204 and 130.94.19.168. Press leads, not relied on for facts: BleepingComputer's report on Check Point's root-access zero-day patch and The Hacker News report on PHP2Shell exploitation of Check Point gateways, both November 2026.
Our earlier PHP2Shell coverage: the October 21 patch post, the October 23 Mirai post, and the October 28 screening of Zscaler's IP table.
Indicators here are Check Point's, cited, not DugganUSA observations. The screening, confidence tiers and edge measurements are ours, done November 13, 2026. We cap ourselves at 95 percent confidence.
Was this useful? Rate this post. The widget is at the bottom of the page, and we read every response.
How do AI models see YOUR brand?
AIPM has audited 250+ domains. 15 seconds. Free while still in beta.
Was this useful? Thirty seconds, no cookies, no tracking, no third parties, your address hashed and never stored. The question lives here: https://analytics.dugganusa.com/nps.html#post=check-point-gateways-were-breached-through-php2shell-then-rooted-through-a-world-writable-socket-i
Comments