PHP2Shell Attacks Use Check Point Gateways to Deploy VMware ESXi Wiper

What happened​

Check Point Research says PHP2Shell provided initial access, followed by privilege escalation through the DynamicCLI interface, tracked as CVE-2026-123039. The attackers then deployed PHP webshells and the TSGA backdoor with its embedded TSProxy component. They pivoted from the gateway to a VMware ESXi host over SSH, deployed the destroy_v6 wiper, and left politically themed DREAM_ANNEXATION.txt notes.

The activity began on October 30. It was seen as active until November 4, according to Check Point's advisory. There were two waves:

• Wave one (October 30): it targeted Israeli organizations, and some of them suffered destructive activity.
• Wave two (November 2): it hit organizations in multiple countries and sectors. Check Point found no evidence of destructive activity in this wave.

Check Point says neither wave showed a clear sector preference. It reads this as opportunistic initial-access attempts, not sector-specific targeting.

Check Point's advisory says the scale was limited. It says fixes were available about a week before the attacks, and that only a couple dozen unpatched systems in a single region were compromised in the incidents it observed. Treat that as the vendor's own count of cases it saw, not a census of all exposed gateways.

The vulnerabilities, and which patch does what​

Three CVEs matter here, and they sit at different layers:

Check Point's advisory lists the PHP2Shell flaws as affecting Security Gateways across R80 through R82.20. It also lists Spark Firewall versions R81.10.x, R82.00.x, R77.20.x and R80.20.x. CVE-2026-123039 is listed for Gaia R81.20, R82, R82.10 and R82.20. Check Point's own advisory marks both as exploited in the wild.

Check Point says its gateway fixes were available on October 23. The general PHP fix came earlier. The PHP project's emergency release on October 21 covered 8.5.12, 8.4.27, 8.3.36 and 8.2.35. Both are folded into the November Jumbo Hotfix. The R82 Jumbo Hotfix Take 132, released November 12, lists fixes for both PHP2Shell CVEs and CVE-2026-123039.

CVE-2026-123039 is described as a flaw in which the DynamicCLI daemon exposes a local world-writable control socket. A low-privileged local foothold therefore becomes root. This is why the chain worked: a web-facing bug gives a low-privileged shell, and the local bug removes the remaining barrier.

The attack chain, step by step​

1. Exploit the portal. Session files appeared under /opt/CPcvpn-R81.20/tmp/ containing the string upload_progress_pwn. Check Point also saw hundreds of segmentation faults in the portal's Apache/PHP workers, consistent with repeated exploitation attempts.
2. Escalate to root via DynamicCLI.
3. Plant webshells. Check Point says they were placed in the Mobile Access templates directory used to build login pages. The files matched zz*.tpl. Early versions were small command shells, later swapped for a more capable one with a hardcoded key. It supports OS commands, PHP execution and file upload.
4. Install persistence. TSGA, launched from /tmp/CPconfigdaemon, relocates itself and restarts as slot_CPconfigdaemon. It carries TSProxy, written to /lib/libcpfwcommon.so. TSProxy is injected into selected appliance processes and intercepts networking functions. Specially marked attacker connections can therefore blend with ordinary traffic.
5. Map the network. The attacker ran the open-source gogo scanner on the gateway.
6. Move to ESXi. The attacker connected over SSH using the vpxuser service account and staged the wiper as /tmp/des.
7. Destroy. destroy_v6 takes a target directory and processes files of any extension. By default it overwrites with zeros before deleting. A -f flag skips the overwrite, and -w excludes listed subtrees. It drops DREAM_ANNEXATION.txt in every directory it processes. The note rejects ransom negotiations.

Check Point says TSGA supports encrypted remote access, configuration theft, backup and snapshot persistence, process injection and tampering with binary firewall logs. The firewall logs are the evidence you would normally use to investigate, which is the nasty part.

Who did it? Check Point says it can't tell​

The attribution picture is deliberately murky. Check Point found that TSGA and TSProxy share distinctive code, configuration and cryptographic material with PhiliKit, a framework previously documented in Ivanti-appliance attacks. ESET linked PhiliKit to the China-nexus cluster UNC5221. Other clues point the same way:

• The gogo scanner has been reported in connection with Chinese-nexus actors.
• The infrastructure was hosted on LightNode VPS, which has been associated with Chinese-nexus activity.
• Scanning was concentrated between 00:00 and 09:00 UTC, which is typical Chinese working hours.

Other features do not fit those groups' usual motives. The operation was destructive. It focused on Israel, and the wiper note was in Hebrew and referred to the Israeli-Palestinian conflict. The malware's internal name, "philistine", is also notable.

Check Point lists several plausible scenarios: one actor ran the whole campaign, the actor acted only as an initial-access broker, or the operation was a false flag. The destruction may also have been a smoke screen. The note uses the Dream Security brand, and Dream had recently published research on PHP2Shell exploitation of Palo Alto Networks devices. Check Point says this raises the possibility of retaliation but does not establish a motive.

My read, which is analysis and not Check Point's finding: don't build your threat model around a named actor. Whoever it was, the techniques are reusable. An edge-device exploit, a root implant, a SSH pivot and a hypervisor wipe will work for anyone.

What administrators should do​

Patch. Check Point recommends installing the November Jumbo Hotfix on all Management Servers and Security Gateways, with internet-facing Mobile Access portals first. Confirm the exact hotfix instructions for your platform and release in Check Point's documentation. Spark devices are listed as affected by PHP2Shell, and Check Point says they should get the latest GA version.

Hunt on previously exposed gateways. Check Point's indicators are:

• PHP session files containing upload_progress_pwn.
• Processes or binaries masquerading as CPconfigdaemon.
• Scanner or wiper tooling under /tmp or /temp.
• A note referencing "Dream Annexation" with no payment demand.
• Unexplained gaps in firewall traffic logs, especially after a logging-daemon crash.
• Unauthorized SSH from gateways to internal ESXi hosts.
• Source addresses 130.94.19[.]204 and 130.94.19[.]168.

Check Point cautions that no match does not rule out compromise. A match warrants immediate investigation. Installing the patch does not prove a previously exposed gateway is clean, because the attackers had root and persistence. If a gateway was exposed while unpatched, consider incident-response help, including from the vendor.

Check the ESXi side too. Review SSH logins to ESXi hosts, especially vpxuser activity originating from gateway addresses. Also review whether SSH on ESXi is enabled at all, and whether gateways need a network path to hypervisor management. The attacker reached ESXi because the route existed. That is general hardening advice rather than a Check Point instruction.

The bigger lesson​

Security appliances are privileged, trusted and often poorly monitored. They also run ordinary web stacks like PHP, which is how a language-level bug became a firewall compromise. A patch gap of about a week was enough here, a reminder that edge-device exploitation now starts within days of a fix. The wipe stage is the grim punchline: anyone who treats a gateway breach as a "network" problem rather than a "your VMs are next" problem is underestimating the blast radius.

Backups matter here too. A wiper that zero-fills files makes recovery from the affected datastore unrealistic, so offline or immutable copies that the gateway and ESXi hosts cannot reach are the practical safeguard. That is industry-standard guidance, not something drawn from the Check Point report.