PHP2Shell Campaign Wiped VMware ESXi Hosts via Check Point Gateways

Attackers began exploiting vulnerable Check Point Security Gateways on October 30 and ended at least one campaign by wiping VMware ESXi hosts with a tool called destroy_v6. Check Point's own researchers disclosed the chain. The first wave hit Israeli organizations. A second wave followed on November 2 and touched companies in multiple countries and sectors.

The entry point was PHP2Shell, the collective name for two critical PHP flaws tracked as CVE-2026-109618 and CVE-2026-109619. Both allow unauthenticated remote code execution. PHP shipped emergency patches on October 21. Amazon Threat Intelligence recorded exploitation attempts starting four days earlier — before the fix existed. That gap matters. It means patched does not mean unbreached.

What did the attackers actually do?

The actor ran the entire operation alone, from initial access through lateral movement to webshell deployment. Check Point describes a single campaign, not a resale of access. The intrusion path is specific:

• Initial access via PHP2Shell through the gateway's Mobile Access portal
• Privilege escalation via a newly disclosed zero-day, CVE-2026-123039, to gain root
• Installation of PHP webshells and a backdoor Check Point calls TSGA
• TSGA embeds TSProxy, a networking component that listens for attacker commands hidden inside regular traffic

So far, so standard for an APT playbook. Then the campaign turned destructive.

In the Israeli attacks, the actor pivoted from the gateway to VMware ESXi hosts. They found those hosts with gogo, an open-source network reconnaissance scanner. On the ESXi machines they deployed destroy_v6, a wiper that recursively deletes data in a target directory. The tool first attempts a zero fill to make recovery harder. It also offers a fast mode that skips overwriting entirely — a convenience feature for an operator who values speed over certainty of destruction.

Was this destruction or a false flag?

Here the evidence gets murky. The attacker left a file named DREAM_ANNEXATION.txt on the ESXi host. It references 'Dream Security Ltd.' and carries political messages. The note explicitly rejects ransom negotiations. That signals the attackers' sole goal was damage and disruption, not profit.

Check Point itself raises the false-flag question. Political messages planted during a destructive stage are cheap to fabricate. Attribution based on a text file left by an intruder deserves skepticism, and the researchers apply it.

There is one tentative technical link. Check Point connects TSGA and TSProxy to PhiliKit, a malware framework previously used against Ivanti appliances. ESET has associated PhiliKit with the Chinese threat cluster UNC5221. But Check Point states plainly that the attacks could not be attributed with confidence based on available evidence. Treat every named-cluster headline about this incident accordingly.

The second wave complicates the picture further. It showed no destructive activity at all. What the attackers did after gaining access in that wave remains unclear — which is arguably worse than a known wiper, because unidentified follow-on actions could still be in progress.

What do regulators and vendors say?

CISA added both PHP2Shell bugs to its Known Exploited Vulnerabilities catalog on October 26. The agency later warned that attackers chain PHP2Shell with the Fragnesia Linux kernel flaw to obtain root privileges. KEV listing means federal agencies must remediate; for private enterprises it functions as a de facto deadline.

Check Point's remediation guidance is concrete. Customers should install the November Jumbo Hotfix on all Management Servers and Security Gateways, prioritizing gateways with internet-facing Mobile Access portals. The update fixes both PHP2Shell and the DynamicCLI privilege escalation flaw used in the attacks.

How do you know if you were hit?

Patching closes the door. It does not evict an intruder who already walked through it. Check Point tells administrators to hunt for compromise indicators on any previously exposed gateway:

• Session files containing the string upload_progress_pwn
• Unexpected CPconfigdaemon processes or binaries
• Unexplained gaps in firewall logs
• Unauthorized SSH activity from the gateway to internal VMware ESXi hosts

The log gaps deserve particular attention, because an attacker with root can erase their own footprints, and a wiper that zero-fills disks can erase the victim's evidence too. Organizations that ran internet-facing Mobile Access portals between October 17 and the hotfix date should assume inspection is mandatory, not optional.

The honest summary: one actor, two waves, one wiper, zero confident attribution. The hotfix addresses the known holes. What happened inside the second wave's victims is a question no one has answered yet.