Check Point Gateway Hack: PHP2Shell, CVE-2026-123039 and the TSGA Backdoor

What happened in the Check Point gateway intrusions

Perimeter security appliances sit on the untrusted edge of the enterprise network while holding deep visibility into internal routing, VPN credentials and management planes. Compromise one and the boundary collapses inward. In late October and early November 2026, a campaign exploited exactly that position. It chained two critical PHP engine vulnerabilities known together as PHP2Shell (CVE-2026-109618 and CVE-2026-109619) with a previously undisclosed local privilege escalation flaw in Check Point’s Gaia operating system (CVE-2026-123039). With root on the gateway, the operators installed a Check Point-aware backdoor suite called TSGA and TSProxy, then moved into internal VMware ESXi hypervisors and wiped storage volumes.

The intrusions came in two phases, which makes attribution harder. On October 30, 2026, about nine days after upstream PHP maintainers patched PHP2Shell, traffic from 130.94.19[.]204 began hitting internet-facing Check Point Mobile Access portals belonging to Israeli organizations. Several of those intrusions ended with a wiper running on internal virtualization infrastructure. On November 2, 2026, a wider wave spread across regions and industries. It revisited some of the earlier Israeli targets along with unrelated organizations worldwide, and it deployed no destructive payloads. Neither wave showed a clear vertical focus, which points to opportunistic initial exploitation followed by selective downstream tasking.

How PHP2Shell (CVE-2026-109618 and CVE-2026-109619) gave attackers the first foothold

The way in was the PHP runtime behind the Mobile Access portal. No flaw in Check Point’s firewall inspection engine was involved. PHP2Shell covers two remote code execution vulnerabilities, CVE-2026-109618 and CVE-2026-109619, both rated CVSS v4.0 9.2 and affecting every PHP version from PHP 5 onward. Upstream maintainers patched both on October 21, 2026. Telemetry shows limited zero-day exploitation before the advisory, then widespread scanning right after it.

CVE-2026-109618 is an unsafe state recovery bug in the Zend Engine’s out-of-memory handling. When a memory allocation fails mid-execution, PHP calls longjmp() to unwind the stack and return to the request-startup environment. If that bailout happens while request-bound data structures are only partly initialized, the engine resumes with malformed pointers and uninitialized memory treated as valid state. Combined with CVE-2026-109619, crafted HTTP requests to an exposed PHP endpoint can corrupt heap metadata and hijack instruction flow reliably enough for arbitrary code execution.

Against Check Point gateways, the exploit leaves plenty of forensic evidence. The operators abused PHP’s session.upload_progress feature to stage serialized state payloads, which produced session artifacts in /opt/CPcvpn-R81.20/tmp/ carrying the literal marker upload_progress_pwn. Heap manipulation through longjmp() bailouts is probabilistic across worker processes, so successful exploitation was preceded by hundreds of segmentation faults in the portal’s Apache and PHP worker daemons. Those crash logs give incident responders a precise window for when the gateway was probed and breached.

Code execution at this stage ran only as the unprivileged portal service account. That was enough to read local web templates and talk to loopback interfaces. It was not enough to modify kernel modules, alter firewall logging binaries or harvest system-wide administrative credentials. For that, the attackers needed a second vulnerability inside Gaia OS.

CVE-2026-123039: the Gaia OS DynamicCLI socket flaw that handed over root

To go from the portal service context to full administrative control, the operators exploited CVE-2026-123039 (CVSS v3.1 7.8, CWE-306, Missing Authentication for Critical Function). The bug sits in the inter-process communication design of Gaia’s DynamicCLI daemon, dynamic_server, which runs as root and handles dynamic command-line configuration requests across Check Point appliances.

In affected releases, dynamic_server bound to a local Unix domain socket at /tmp/dynamic_socket with world-writable permissions (0777). It performed no peer credential check (SO_PEERCRED) and no session token validation. Any local user or compromised service account that could write bytes to the socket could submit arbitrary commands and have dynamic_server run them as root. The affected releases are R81, R81.10, R81.20, R82, R82.10 and R82.20, across Quantum Security Gateways, Force Firewalls, Security Management and Log Servers, Multi-Domain Security Management environments and Maestro Orchestrators.

Affected Gaia releases and fixed Jumbo Hotfix versions

Affected release train	Remediation Jumbo Hotfix	Socket permission after fix
Gaia R81.20	R81.20 Take 174	0660 (root:config)
Gaia R82	R82 Take 132	0660 (root:config)
Gaia R82.10	R82.10 Take 52	0660 (root:config)
Gaia R82.20	R82.20 Take 14	0660 (root:config)

Check Point’s November 13, 2026 security advisory confirmed active exploitation of CVE-2026-123039 against roughly two dozen customer environments before a patch existed. Because the socket accepted raw command payloads without routing them through the restricted Clish shell wrapper, exploitation left distinctive entries in /var/log/dynamicCli.log. Legitimate administrative actions pass through Clish parsing, while socket-level exploits call the system() execution sink directly. The Jumbo Hotfix takes fix the flaw by restricting /tmp/dynamic_socket to 0660 under root:config ownership, which cuts unprivileged local daemons off from dynamic_server.

TSGA backdoor and TSProxy: how the attackers stayed on the gateway

Once CVE-2026-123039 produced root, the attackers built two layers of persistence meant to survive service restarts, configuration backups and routine admin audits.

The first layer was a set of PHP web shells written into the Mobile Access portal’s login template directory, so they could be called over HTTPS next to legitimate authentication pages. The operators first decoded lightweight dropper shells into files named zz*.tpl (such as /zz.tpl) using base64 redirection (printf | base64 -d). Those stagers were soon replaced by a sturdier web shell gated behind a hardcoded authentication parameter, zz2026. It ran shell commands, evaluated raw PHP, and handled staged file uploads by writing incoming payloads to /tmp/.up.tpl and then copying them into the portal’s active template path as challenge_render.tpl. To dodge passive network inspection, command traffic to the shell could be plaintext or Base64-encoded with XOR obfuscation.

The second layer was TSGA, a passive Linux backdoor built around Check Point’s internal OS layout. It was staged at /tmp/CPconfigdaemon to resemble legitimate Check Point configuration binaries and launched detached from the terminal with nohup /tmp/CPconfigdaemon >/tmp/.bd.log 2>&1 &. On detecting root, TSGA copied itself into the appliance’s boot persistence directory as slot_CPconfigdaemon and respawned, which kept it alive across cold reboots.

TSGA shows detailed knowledge of Gaia OS internals:

• It hooks Gaia’s backup and system snapshot routines, so the implant survives even when an administrator rolls back configuration changes or restores a local snapshot.
• It can edit Check Point’s proprietary binary firewall log files directly on disk, scrubbing connection records tied to the operators’ command-and-control (C2) sessions without corrupting the surrounding log headers.
• It harvests gateway configuration files, including VPN pre-shared keys, certificate material, routing tables and the SIC (Secure Internal Communication) trust parameters used to authenticate with management servers.
• It carries an embedded shared object, TSProxy, written to /lib/libcpfwcommon.so to blend in with genuine Check Point firewall libraries. TSGA injects that library into running appliance daemons, where it hooks the networking functions accept, recv and read. When a TCP stream carries a specific magic byte sequence, TSProxy takes over the socket and opens an encrypted SOCKS-style proxy tunnel. Ordinary enterprise traffic passes through to the underlying daemon untouched.

Code analysis ties TSGA and TSProxy to PhiliKit, a modular Linux implant framework ESET first documented in June 2026 during investigations into Ivanti VPN compromises attributed to the China-nexus espionage cluster Armory Castle (formerly tracked as UNC5221). TSGA and earlier PhiliKit builds share their cryptographic framing and command loop, both derived from Tiny SHell. Both use the Unix domain socket /tmp/.p_sock and listen on TCP port 11072. The difference is the bind address. Earlier PhiliKit samples bound port 11072 to 127.0.0.1 for local port forwarding, while TSGA binds to all IPv4 interfaces (0.0.0.0), which allows direct passive connections from compromised internal segments or exposed management interfaces.

From Check Point to ESXi: lateral movement and the destroy_v6 wiper

With persistent root on the perimeter gateway, the operators turned to internal discovery and destruction in a subset of the October 30 Israeli intrusions. They uploaded gogo, an open-source Go network scanner known for fast asynchronous port and service enumeration, to map the subnets reachable behind the firewall.

Using that topology and credentials harvested during post-exploitation, they opened outbound SSH sessions from the compromised gateway to internal VMware ESXi hosts. Authentication worked with the vpxuser account, the privileged local account that vCenter Server creates and manages to administer each ESXi hypervisor. With vpxuser credentials, the attackers skipped the usual administrative bastions and got root-equivalent shell access on the hypervisor itself.

On the targeted hosts they staged a Linux ELF wiper at /tmp/des, referred to in technical reporting as destroy_v6. It takes a target directory as its main positional argument and two optional flags: -f for fast unlinking without overwriting file contents, and -w to supply a pipe-delimited list of directories to skip. Run without -f, destroy_v6 walks the target tree recursively and hits virtual machine disk images (.vmdk), snapshots and configuration files regardless of extension. It overwrites every file with null bytes (0x00) before unlinking it, which defeats block-level forensic recovery.

In every directory it processes, destroy_v6 drops a text file named DREAM_ANNEXATION.txt. The note contains a timestamp, explicit political messaging about the Israeli-Palestinian conflict, a rejection of ransom negotiations, and a direct mention of the Israeli cybersecurity firm Dream Security. Dream Security had recently published research linking China-nexus threat actors to PHP2Shell exploitation against Palo Alto Networks perimeter appliances, so the wording may add a retaliatory angle or an attempt to muddy the signal.

Who is behind it? Conflicting attribution signals

The evidence points in two directions: the tooling lineage says one thing and the final objective says another.

Several technical and behavioral indicators fit a China-nexus actor, specifically Armory Castle (UNC5221) or an affiliate with access to the PhiliKit codebase. Beyond the shared cryptographic structure, the /tmp/.p_sock path and the TCP 11072 listener that link TSGA to PhiliKit, infrastructure analysis found staging servers on LightNode VPS instances. Scanning and exploitation telemetry also clustered between 12:00 and 09:00 UTC, which matches business hours in China (UTC+8).

Against that, a wiper that overwrites files with zeros on VMware ESXi hosts, paired with politically charged ransom-rejection notes, sits poorly with established Chinese state espionage practice. That practice overwhelmingly favors quiet, long-term intelligence collection over noisy infrastructure destruction. Check Point’s threat intelligence team said current telemetry cannot separate several hypotheses: a single China-nexus group running an atypical destructive operation, an initial access broker (IAB) monetizing opportunistic PHP2Shell breaches by handing select Israeli targets to a politically motivated or hacktivist actor, or a deliberate false flag meant to hide the real sponsor of the October 30 strikes.

How to detect and remediate: Check Point threat hunting checklist

Treat CVE-2026-123039 and PHP2Shell as an active intrusion vector that needs both immediate patching and forensic verification. Apply the November 2026 Jumbo Hotfix (R81.20 Take 174, R82 Take 132, R82.10 Take 52 or R82.20 Take 14) to close the /tmp/dynamic_socket permissions hole. If you cannot schedule a maintenance window right away, you can temporarily block the local privilege escalation by stopping the dynamic_server daemon and preventing its automatic respawn. That disables DynamicCLI functionality until you patch.

Patching a gateway that is already compromised will not remove the backdoor, because TSGA embeds itself in boot persistence directories and in Gaia backup and snapshot archives. Audit exposed Mobile Access gateways and downstream ESXi hypervisors for these high-confidence artifacts:

• PHP2Shell traces. Look in /opt/CPcvpn-R81.20/tmp/ (and the equivalent path for other versions) for PHP session files containing upload_progress_pwn, and for spikes in Apache or PHP worker segmentation faults on or after October 21, 2026.
• Web shells. Check the Mobile Access portal template directories for unexpected zz*.tpl files, unauthorized changes to challenge_render.tpl, and /tmp/.up.tpl.
• DynamicCLI socket abuse. Review /var/log/dynamicCli.log for commands that hit the system() sink or ran outside the Clish wrapper, and confirm /tmp/dynamic_socket is 0660 and not 0777.
• TSGA and TSProxy persistence. Check running processes, startup directories and system snapshots for CPconfigdaemon or slot_CPconfigdaemon. Compare the hash of /lib/libcpfwcommon.so against clean vendor images, and inspect active sockets for listeners on TCP port 11072 or /tmp/.p_sock.
• ESXi lateral movement. Correlate outbound SSH logs on the gateway with ESXi auth.log entries for vpxuser logins that came from firewall interfaces instead of vCenter management appliances, and scan datastores for /tmp/des or DREAM_ANNEXATION.txt.

If any of these indicators turn up, in-place cleanup will not be enough, because TSGA manipulates binary logs and persists through snapshots. Rebuild the affected gateways from verified clean installation media, and rotate every SIC certificate, VPN secret and downstream hypervisor credential immediately.