From a VPN Portal to an ESXi Wiper: Inside the Check Point Gateway Intrusions (PHP2Shell and CVE-2026-123039)

A firewall is supposed to be the thing that stops an intrusion, not the place one begins. Check Point has now described how attackers turned roughly two dozen of its unpatched Security Gateways into exactly that: they broke in through the Mobile Access portal, took root on the appliance, hid an implant inside it and, in a small number of cases, reached across to VMware ESXi hosts and wiped them. Fixes had been available for a week before the first attack. This is what happened, how to tell whether it happened to you, and what to do first.

Entry	PHP2Shell (CVE-2026-109618/-109619, 9.2), Mobile Access portal
To root	CVE-2026-123039 (7.8), Gaia DynamicCLI
Scale	“A couple of dozen” unpatched systems, one region
Fix	November Jumbo Hotfix on gateways and management

What happened

[Confirmed] Check Point says attackers exploited PHP2Shell, a PHP flaw that also affects its Security Gateways, through the Mobile Access portal. They then used a Gaia privilege-escalation flaw, CVE-2026-123039, to get root and persistence. Activity ran from 30 October to 4 November, a week after fixes shipped on 23 October. Only “a couple of dozen unpatched systems, in a single region” were compromised. In many cases the attacker got a foothold in the network; in a limited number the activity was destructive and ideologically motivated. Check Point notified affected customers and helped remediate. (Check Point advisory)

[Confirmed] Check Point Research describes two waves. The first, on 30 October, targeted Israeli organisations and included destructive activity against some. The second, on 2 November, hit organisations in several countries and sectors with no sign of destruction. (Check Point Research)

Who is affected

CVE	What	Affected	Exploited
CVE-2026-109618 / -109619	PHP2Shell: unauthenticated RCE via firewall web interfaces (9.2)	Security Gateways with Mobile Access Portal, R80 to R82.20; Spark R81.10.x, R82.00.x, R77.20.x, R80.20.x	Yes
CVE-2026-123039	Local privilege escalation in the Gaia DynamicCLI service (7.8)	Gaia R81.20, R82, R82.10, R82.20	Yes
CVE-2026-107484	Gaia Portal privilege escalation by an authenticated user (7.3)	Gaia WebUI R80 to R82.20	No
CVE-2026-120490	Management-to-gateway access via NAT rule (3.8)	R81.20, R82	No

Source: Check Point advisory (SK references sk1000302, sk1000362, sk1000291, sk1000364). The November Jumbo Hotfix also includes the Node2Shell/Brotli fix CVE-2026-111497.

How the attack works

[Confirmed] In the intrusion Check Point investigated, the attacker:

1. Exploited the portal, leaving PHP session files with upload_progress_pwn under /opt/CPcvpn-R81.20/tmp/ and causing hundreds of Apache/PHP worker crashes.
2. Escalated from the portal’s service account to root through DynamicCLI.
3. Wrote PHP web shells as zz*.tpl login-page templates, using the key zz2026, with uploads saved to /tmp/.up.tpl.
4. Launched the TSGA implant from /tmp/CPconfigdaemon, which relaunches as slot_CPconfigdaemon. TSGA drops TSProxy to /lib/libcpfwcommon.so and injects it into appliance processes to hide attacker connections. It can also steal configuration, persist in backups and snapshots, and tamper with firewall logs.
5. Scanned the internal network with the gogo scanner, then used SSH as vpxuser to reach a VMware ESXi host and run the destroy_v6 wiper, which left DREAM_ANNEXATION.txt notes rejecting ransom.

(Check Point Research) [Unknown] How the attacker obtained a working ESXi credential. [Reported] TSGA and TSProxy are modified variants of PhiliKit, a backdoor seen in Ivanti VPN attacks that ESET associated with China-nexus UNC5221. Check Point says the evidence doesn’t support a confident attribution: the actor may have run the whole campaign, acted as an access broker, or staged a false flag.

Gateway and ESXi hunt

OS: Gaia (expert mode) · ESXi shell · Shell: bash / sh · Privileges: expert (root) · ESXi admin · READ-ONLY

# Gaia: installed Jumbo Hotfix take
cpinfo -y all 2>/dev/null | grep -i -A2 'HOTFIX'
# Portal exploitation marker and template web shells
grep -l 'upload_progress_pwn' /opt/CPcvpn-*/tmp/sess_* 2>/dev/null
find / -xdev \( -name 'zz*.tpl' -o -name 'challenge_render.tpl' -o -name '*CPconfigdaemon' \
  -o -name 'libcpfwcommon.so' \) 2>/dev/null
ls -la /tmp/.bd.log /tmp/.up.tpl /tmp/.p_sock 2>/dev/null
netstat -tlnp 2>/dev/null | grep ':11072'
# ESXi: SSH logins as vpxuser (run on each host)
grep -i 'vpxuser' /var/log/auth.log | grep -i 'sshd'

Expected clean result: a current November take, and no output from the other commands. Any hit means a full compromise: isolate the device and call incident response before changing it. Commands not tested by MAG212 CYBER. Indicators from Check Point Research; check exact paths against your Gaia version.

Investigate, contain and remediate (in order)

1. Preserve evidence off the box first: remote syslog, SmartConsole logs, upstream NetFlow and vCenter/ESXi auth logs. TSGA can tamper with local firewall logs, so gaps after a logging-daemon crash are themselves a signal.
2. Block 130.94.19[.]204 and .168, and restrict traffic from gateways to hypervisor management networks.
3. Install the November Jumbo Hotfix on all management servers and gateways, internet-facing Mobile Access first (for example R81.20 Take 174, R82.10 Take 52). (R81.20) (R82.10)
4. [MAG212 analysis] If any indicator matches, rebuild rather than clean. TSGA persists in backups and snapshots, so check backups before restoring. Then rotate VPN, admin and vpxuser/vCenter credentials.

Verify recovery: the take is confirmed on both cluster members; there’s no listener on 11072; ESXi shows no SSH from gateways; and policy install, VPN login and failover work. Prevention [MAG212 analysis]: a firewall should never be able to SSH to your hypervisors. Put ESXi management behind its own boundary, disable ESXi SSH when it’s not in use, and keep firewall logs somewhere the firewall can’t edit.

What makes this intrusion different

[MAG212 analysis] Exploited VPN appliances are not new. What stands out here is how far the attacker went after the initial break-in. Root on a gateway gave them a position that most security tools can’t see into: the implant hid its own network connections inside legitimate appliance processes, and Check Point Research says it could tamper with the firewall’s own logs. From there, the attacker treated the firewall as a jump host into the data centre.

[MAG212 analysis] The destructive stage targeted virtualisation, not individual servers. Wiping an ESXi host takes down every virtual machine on it at once, which is why ransomware crews have focused on hypervisors for years. Here there was no ransom: the note rejected payment, and Check Point describes the destructive activity as ideologically motivated. That makes backups and recovery speed, not negotiation, the only defence.

[Reported] Attribution is unresolved. The implant is a modified version of a backdoor seen in earlier Ivanti VPN attacks, but Check Point says the evidence fits several explanations, including an access broker or a deliberate false flag. Defenders don’t need to settle that question to act: the indicators and the fixes are the same.

Why it matters

Edge devices and hypervisors are two of the most valuable systems in any network, and this campaign joined them. Every organisation that runs a VPN appliance in front of a virtualised data centre should ask whether the firewall can talk to the hypervisor’s management interface. In this intrusion it could, and that single path turned a perimeter compromise into destroyed infrastructure. The week between the fix and the first exploitation is also a reminder that patch windows for edge devices are now measured in days.

The bottom line

Install the November Jumbo Hotfix on every Check Point gateway and management server, starting with internet-facing Mobile Access. Run the hunt on each gateway and check ESXi for SSH logins from the firewall. If anything matches, preserve the logs off the box, rebuild rather than clean, rotate VPN, admin and vCenter credentials, and cut the network path from gateways to hypervisor management for good.

How we label evidence: [Confirmed] comes from a primary source such as a vendor or CISA; [Reported] from a secondary outlet; [Claimed] from an attacker or an unverified party; [MAG212 analysis] is our judgement; [Unknown] means not established at press time. Commands and indicators are copied from the cited sources and were not tested by MAG212 CYBER.

---

This story is part of MAG212 CYBER Daily, 13 November 2026, with the day’s other verified stories, the Defender’s Action Desk and a full source register. Get the daily briefing free: subscribe to MAG212 CYBER. By El Mostafa Ouchen.