Check Point gateways rooted via PHP2Shell and a Gaia flaw

Attackers have been breaking into Check Point Security Gateways since late October. They get in through the Mobile Access portal with the PHP2Shell flaws, become root through a Gaia OS bug Check Point has just disclosed, and in some cases go on to wipe VMware ESXi hosts. On Friday, November 13, 2026, CISA added the root flaw, CVE-2026-123039, to its exploited list. The federal deadline is Monday, November 16. If you manage Check Point gateways or management servers, install the November Jumbo Hotfix this weekend and check each one for signs of compromise.

PHP2Shell was the way in

The entry point is the portal, not a new remote flaw. Check Point Research says the attacker went after unpatched gateways whose Mobile Access portals were vulnerable to PHP2Shell (CVE-2026-109618 and CVE-2026-109619). This site has followed PHP2Shell since the October 26 briefing. The October 29 briefing covered another group using it to root firewalls at another vendor.

Check Point Research says the activity began about one week after a security fix became available. It does not name that fix. The targets were gateways that had not applied it.

A local Gaia flaw turned the foothold into root

CVE-2026-123039 is a local privilege escalation in Gaia OS, rated CVSS 7.8. Check Point's advisory sk1000362 says the root-owned DynamicCLI daemon listens on /tmp/dynamic_socket. Any local process can write to that socket, and the daemon does not check who sent a command. So code running as the portal's service account can run commands as root.

Check Point says it saw the flaw exploited against "a couple of dozen customers." Exploitation requires code already running on the appliance, which PHP2Shell provided.

Check Point Research describes what came next. The attacker hid PHP webshells in the portal's templates directory. It installed a backdoor Check Point calls TSGA, with a built-in proxy component called TSProxy, and scanned the internal network with an open-source tool called gogo. From the gateway it logged in over SSH to an ESXi host with the vpxuser account and ran a wiper called destroy_v6. Check Point links TSGA to PhiliKit, a toolkit earlier seen in attacks on Ivanti appliances, but says the evidence does not support a confident attribution.

Timeline

Date	Event
About October 17	Exploitation attempts against PHP2Shell begin, four days before the PHP fixes, per Amazon Threat Intelligence as reported by BleepingComputer
October 21	PHP releases emergency fixes for PHP2Shell
October 30	First wave against Check Point gateways, aimed at Israeli organizations; destructive activity at some victims
November 2	Second wave across multiple countries and sectors; Check Point saw no destructive activity
November 8	Check Point publishes sk1000362 for CVE-2026-123039
November 12	Check Point Research publishes its write-up of the campaign
November 13	CISA adds CVE-2026-123039 to the KEV catalog, due November 16, with forensic triage required

Who is exposed

Check Point lists these as affected: Force Firewalls, Management and Log Servers, Multi-Domain Security Management and Multi-Domain Log Server, and Maestro Orchestrator. Affected versions are R82.20, R82.10, R82, R81.20, R81.10 and R81.

Spark Firewalls and Smart-1 Cloud are not affected. That matters for MSPs, because many small offices run Spark appliances. Check that before you plan weekend work.

The highest risk sits with gateways that run Mobile Access on an internet-facing portal and missed the late-October fixes. Those gateways may already be compromised, so patch them and investigate them. Clients that run ESXi on a network reachable from the gateway are exposed to the destructive part of the chain.

What to do

Patch. Install the November Jumbo Hotfix on every management server and gateway. Per BleepingComputer, Check Point says to start with gateways that expose Mobile Access portals. These are the first fixed takes listed in sk1000362:

Version	Fixed in
R82.20	Jumbo Hotfix Take 14 and later
R82.10	Jumbo Hotfix Take 52 and later
R82	Jumbo Hotfix Take 132 and later
R81.20	Jumbo Hotfix Take 174 and later
R81.10, R81	No fix; end of support. Mitigate, then upgrade

Mitigate where you cannot patch yet. Check Point's interim step is to stop the dynamic_server process and keep it from restarting. sk1000362 gives the exact commands. This disables the Dynamic CLI commands described in sk144112.

Confirm the fix. On a fixed system, /tmp/dynamic_socket is owned by root, group config, with mode 0660. A vulnerable system shows it as world-writable (0777).

Hunt on every gateway that ran Mobile Access before it was patched. CISA flags this entry for forensic triage, and the advisory and research give enough to start:

Read /var/log/dynamicCli.log. Look for commands without the normal Clish wrapper, and for Received = #return_value#, which shows the system() path. Search for id, whoami, /etc/shadow, nc, curl, wget, base64, useradd and authorized_keys.
After patching, Rejected connection from unauthorized uid with a non-zero UID such as 99 means something tried the escalation and was blocked. Match those times against portal and authentication logs.
Look for unexplained gaps in firewall logs. TSGA can tamper with binary firewall logs.
Treat SSH from a gateway to an ESXi host as a sign of compromise. Check ESXi logs for vpxuser logins that came from a gateway address.

If you find a match, take the gateway out of service and rebuild it. Then rotate every credential it held, including VPN, administrator and directory accounts. Check ESXi hosts and backups before anything else, since the wiper targets them.

Indicators

These come from Check Point Research, which also publishes SHA-256 hashes for the webshell, TSGA, gogo and the wiper. Take the hashes from the report itself.

Indicator	What it is
`130.94.19[.]204`	Attacker address
`130.94.19[.]168`	Attacker address
PHP session files in `/opt/CPcvpn-R81.20/tmp/` containing `upload_progress_pwn`	PHP2Shell exploit attempt on the portal
Spikes of segmentation faults in the portal's Apache or PHP workers	Exploit attempts
`zz<random>.tpl` in the portal templates directory, `/tmp/.up.tpl`, an extra `challenge_render.tpl`	Webshells
`/tmp/CPconfigdaemon`, `slot_CPconfigdaemon`, `/tmp/.bd.log`	TSGA dropper, persistent copy and log
`/lib/libcpfwcommon.so`, `/tmp/.p_sock`	TSProxy library and socket
A listener on TCP port 11072 on all IPv4 interfaces	TSGA backdoor
`/tmp/des` on ESXi, `DREAM_ANNEXATION.txt` on gateways or ESXi	Wiper staging and note

The Canadian Centre for Cyber Security advisory lists a second Check Point flaw: CVE-2026-107484, a Gaia Portal privilege escalation by an authenticated user, in sk1000291. It is not on CISA's exploited list. Check that the hotfix you install covers it as well.

Also today

Update: Agent2Shell also needs the N-central Legacy API. This follows the November 13 briefing, which said N-able had not stated whether agents block the second chain. According to Huntress, N-able confirmed on November 13 that Agent2Shell, like 4EverAble2Shell, works only when the non-default Legacy API is on. N-able has also published indicators for customers who had not disabled it. Huntress lists outbound traffic to 157.20.241[.]16 on ports 8080 and 19202 to 19418, to 139.99.69[.]109:10128, and to 79.76.51[.]56:39100. It also lists the URL paths /jup.sh, /xvgz, /xmrig.tgz, /ob/cronhit and /ob/fcheck on 157.20.241[.]16:8080. Add the two new addresses to your firewall and DNS log searches. Disabling the Legacy API is still the fix for now. N-able has given no date for the next hotfix.

UnrealIRCd. CISA also added CVE-2026-114713, an UnrealIRCd flaw, to the KEV catalog on November 13. Few small businesses run IRC servers. If a client does, update it.