Protect Check Point gateways from PHP2Shell and ESXi wipers

#What happened

Attackers used PHP2Shell vulnerabilities in Check Point Security Gateways to break into organizations. In some cases, they reached VMware ESXi hosts and deployed a data wiper.

The first reported activity began on October 30, 2026, targeting Israeli organizations. A second wave on November 2 reached organizations in multiple countries and sectors. BleepingComputer reported the campaign on November 13.

The practical concern is that an internet-facing Mobile Access portal may provide a path into the systems behind a gateway. And patching alone won’t tell you whether attackers got in before the fix. Check Point recommends installing its November Jumbo Hotfix and investigating gateways that were previously exposed.

#How it works

PHP2Shell refers to two critical PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, that allow unauthenticated remote code execution on vulnerable systems. PHP released emergency fixes on October 21. Amazon Threat Intelligence reportedly saw exploitation attempts begin four days earlier, and CISA added both flaws to its Known Exploited Vulnerabilities catalog on October 26.

Check Point says attackers used the flaws to gain access through gateways’ Mobile Access portals. They then exploited a separate local privilege-escalation issue, CVE-2026-123039, to gain root privileges. That distinction matters: initial code execution and root access give an attacker different levels of control over an appliance.

The reported chain continued with PHP webshells and a backdoor called TSGA. TSGA includes a networking component named TSProxy, which can conceal attacker commands in regular traffic.

In the destructive cases, attackers moved from the gateway to VMware ESXi hosts over SSH. They used the open-source gogo scanner for network reconnaissance, then ran destroy_v6, a wiper that recursively deletes data. The wiper can overwrite data with zeros before deleting it, making recovery harder, or run in a faster mode that skips overwriting.

flowchart LR
    A["Exposed Mobile Access portal"] --> B["PHP2Shell remote code execution"]
    B --> C["CVE-2026-123039 privilege escalation"]
    C --> D["Webshells and TSGA backdoor"]
    D --> E["SSH movement to VMware ESXi"]
    E --> F["destroy_v6 data wiping"]

The first wave targeted Israeli organizations, and some of those organizations later faced destructive activity. Check Point reported that the November 2 wave affected organizations across countries and sectors, but did not include the destructive activity described in the first wave. The follow-on actions in those cases remain unclear.

Check Point also found a file named DREAM_ANNEXATION.txt on an ESXi host. It contained political messages and rejected ransom negotiations. Those messages show what the attackers left behind, but they don’t prove who was responsible.

Check Point tentatively linked TSGA and TSProxy to the PhiliKit framework, but said it couldn’t attribute the campaign with confidence.

#Am I affected?

Start by checking whether your organization runs Check Point Security Gateways with internet-facing Mobile Access portals. Those portals were the reported route for initial access. Treat any gateway exposed during the campaign period as worth investigating, even if it has since been patched.

For CVE-2026-123039, The Hacker News reports that affected product versions include R82.20, R82.10, R82, R81.20, R81.10, and R81. The listed products are Check Point Force Firewalls, Management and Log Servers, Multi-Domain Security Management and Multi-Domain Log Server, and Maestro Orchestrator.

Check your vendor’s current advisory for the exact product and hotfix status in your environment. The source reports that the November Jumbo Hotfix addresses the issue.

On gateways and the systems that collect their telemetry, look for the indicators Check Point called out:

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

A search through a preserved triage copy can help find the named strings. This command searches only the directory you provide. It doesn’t check for every possible indicator or prove that a host is clean.

grep -RniE 'upload_progress_pwn|CPconfigdaemon' /path/to/triage

Use centralized logging and network telemetry where possible. Local firewall logs may have gaps, and attackers were reported to tamper with logs, so not finding an indicator on the appliance isn’t conclusive.

#How to fix or mitigate it

Prioritize these actions:

1. Install the November Jumbo Hotfix on Check Point Management Servers and Security Gateways. Check Point recommends prioritizing gateways with internet-facing Mobile Access portals. The update addresses PHP2Shell and the DynamicCLI privilege-escalation flaw.
2. Review exposed gateways for compromise. Check gateway files, process listings, firewall logs, and centralized telemetry for the indicators above. Look for outbound SSH from gateways to ESXi hosts.
3. Investigate reachable VMware hosts. Review SSH access and host activity around the period when the gateway was exposed. If you find evidence of the wiper, follow your organization’s recovery and incident-response procedures. Don’t rely on the appliance’s local logs alone.
4. Escalate suspected breaches. A patch prevents exploitation of the fixed flaws, but it doesn’t remove webshells, a backdoor, or other access established before patching. Preserve relevant evidence and assess the gateway and connected systems before returning them to service.

The source doesn’t provide a universal log path or a complete detection rule set, so don’t treat one grep result as a full investigation. Use Check Point’s current advisory and your own logging pipeline to confirm the right checks for your appliance version.

#Lessons for your team

A perimeter appliance is part of your production infrastructure. It can hold privileged access to internal networks, so a gateway compromise can become an incident involving virtualization hosts and business data. Assess the path beyond the appliance, not only whether the appliance itself is patched.

This campaign also shows why patching and evidence collection need to happen together. PHP’s fixes were released on October 21, CISA added the flaws to its KEV catalog on October 26, and reported Check Point attacks began on October 30.

When an internet-facing service has had a known remote-code-execution flaw, patching should be followed by a check for earlier access.

#What to do next

If your organization operates Check Point gateways, confirm the hotfix status, starting with internet-facing Mobile Access portals. Then review the gateways and their reachable ESXi hosts for the reported indicators.

I’d treat a clean patch status as necessary, but not as evidence that no earlier compromise occurred.

#Key takeaways