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.

Entrée	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
Réparer	November Jumbo Hotfix on gateways and management

Ce qui s'est passé

[Confirmé] 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)

[Confirmé] 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. (Recherche sur les points de contrôle)

Qui est concerné ?

CVE	Quoi	Affecté	Exploité
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	Oui
CVE-2026-123039	Local privilege escalation in the Gaia DynamicCLI service (7.8)	Gaia R81.20, R82, R82.10, R82.20	Oui
CVE-2026-107484	Gaia Portal privilege escalation by an authenticated user (7.3)	Gaia WebUI R80 to R82.20	Non
CVE-2026-120490	Management-to-gateway access via NAT rule (3.8)	R81.20, R82	Non

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

Comment fonctionne l'attaque

[Confirmé] 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 à /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.

(Recherche sur les points de contrôle) [Inconnu] How the attacker obtained a working ESXi credential. [Signalé] 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. Commandes non testées par MAG212 CYBER. Indicateurs de Recherche sur les points de contrôle; check exact paths against your Gaia version.

Enquêter, contenir et remédier (dans cet ordre)

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. Bloc 130.94.19[.]204 et .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. [Analyse MAG212] 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.

Vérifier la récupération : 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. Prévention [Analyse MAG212]: 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

[Analyse MAG212] 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.

[Analyse MAG212] 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.

[Signalé] 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.

Pourquoi c'est important

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.

En résumé

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.

Comment nous étiquetons les preuves : [Confirmé] provient d'une source primaire telle qu'un fournisseur ou la CISA ; [Signalé] à partir d'une sortie secondaire ; [Revendiqué] d'un attaquant ou d'une partie non vérifiée ; [Analyse MAG212] est notre jugement; [Inconnu] Les termes « non établi » n'étaient pas encore disponibles au moment de la publication. Les commandes et indicateurs sont tirés des sources citées et n'ont pas été testés par MAG212 CYBER.

---

Cette histoire fait partie de MAG212 CYBER Daily, 13 November 2026, Retrouvez également les autres informations vérifiées du jour, la rubrique Action Desk du Defender et un registre complet des sources. Recevez gratuitement le briefing quotidien : abonnez-vous à MAG212 CYBER. Par El Mostafa Ouchen.