PHP2Shell Attacks on Check Point Gateways Deploy Data Wiper on VMware ESXi Hosts

Threat actors are exploiting vulnerable Check Point Security Gateways in a campaign that ends with data-wiping malware on VMware ESXi hosts. According to Check Point Research, the attacks began on October 30, 2026, first against Israeli organizations. A single actor ran the whole operation, from initial access to lateral movement and destruction.

Background: PHP2Shell
PHP2Shell is the name for two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that allow unauthenticated remote code execution. Key dates:

• October 17: Exploitation attempts begin, four days before patches, according to Amazon Threat Intelligence
• October 21: PHP releases emergency patches
• October 26: CISA adds both flaws to its Known Exploited Vulnerabilities (KEV) catalog
• CISA later warned that attackers were chaining PHP2Shell with the Fragnesia Linux kernel flaw to gain root privileges

Two waves of attacks

• Wave 1 (from October 30): Targeted Israeli organizations and included the destructive wiper stage.
• Wave 2 (November 2): Hit companies across multiple countries and sectors. It did not include destructive activity, but what the attackers did afterwards is still unclear.

The attack chain

1. Initial access: The attacker exploited PHP2Shell through the gateway’s Mobile Access portal.
2. Privilege escalation: They then exploited CVE-2026-123039, a newly disclosed zero-day in Check Point’s DynamicCLI, to gain root.
3. Persistence: With root access, they installed PHP webshells (named zz<random>.tpl) and the TSGA backdoor. TSGA drops a networking component called TSProxy, which listens for attacker commands hidden in regular traffic.
4. Lateral movement: In the Israeli attacks, they used gogo, an open-source network scanner, to find VMware ESXi hosts, then reached them over SSH from the gateway.
5. Destruction: Finally, they deployed destroy_v6, a wiper that recursively deletes data in a target directory. By default it first overwrites data with zeros to make recovery harder. It also has a “fast mode” that skips this step.

Webshell analysis
The PHP webshell Check Point shared is small but fully featured:

• Without the correct secret key parameter, it returns an HTTP 404, so it looks like a missing page.
• It runs operating system commands sent either in plain text or base64-encoded and XOR-encrypted with the key, to avoid detection.
• It can run arbitrary PHP code through eval().
• It accepts file uploads, saved as /tmp/.up.tpl, and replies “UPOK” when an upload succeeds.

A political note and a possible false flag
On the ESXi hosts, the attacker left a note named DREAM_ANNEXATION.txt, written in English and Hebrew. It claims to come from “Dream Security Ltd.” and frames the attack as an “annexation” of the victim’s internal network. It contains political messages referring to Israel’s recent inconclusive election, and it explicitly rejects ransom negotiations. That points to the attack’s only goal being damage and disruption, not financial gain.

The note’s use of a real company name, together with the technical links to other actors described below, suggests the claim may be meant to mislead. There is no evidence that the named company was involved.

Attribution
Check Point tentatively linked TSGA and TSProxy to PhiliKit, a malware framework previously seen in attacks on Ivanti appliances. ESET has associated PhiliKit with the China-nexus threat cluster UNC5221. However, Check Point says the attacks cannot be attributed with confidence based on the available evidence.

Indicators of compromise

Recommendations

• Patch immediately: Install Check Point’s November Jumbo Hotfix on all Management Servers and Security Gateways, starting with those that have internet-facing Mobile Access portals. The update fixes both PHP2Shell and the DynamicCLI privilege escalation flaw.
• Hunt for compromise on previously exposed gateways:
  • Session files containing upload_progress_pwn
  • Unexpected CPconfigdaemon processes or binaries
  • Webshells matching zz*.tpl, or the file /tmp/.up.tpl
  • Unexplained gaps in firewall logs
• Check for lateral movement: Treat any unauthorized SSH activity from the gateway to internal VMware ESXi hosts as a clear sign of breach.
• Block and hunt for 130.94.19[.]204 in perimeter and gateway logs.
• Protect ESXi environments: Restrict SSH access to ESXi hosts, disable SSH when not needed, and allow management access only from dedicated admin networks.
• Check backups: Keep offline or immutable backups of critical virtual machines. The wiper is built to make recovery hard.
• Treat patched-but-exposed gateways as possibly compromised: Patching doesn’t remove an attacker who already has root access and a backdoor installed.

We will update this post as more details about the campaign and its attribution emerge.