PHP2Shell Flaws Used to Break Into Check Point Gateways and Wipe an ESXi Host

Check Point has reported attacks in which intruders used the PHP2Shell vulnerabilities to get into its gateway appliances, escalated to root, and in one wave wiped a VMware ESXi host. SecurityWeek wrote up the vendor's account on 13 November.

The PHP2Shell pair are CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS 4.0 by the PHP project. They were patched on 21 October. Exploitation began days before the patches and picked up shortly after, according to the report.

What happened

There were two waves. The first started on 30 October and hit Israeli organizations; it was destructive. The second started on 2 November and went after organizations in several countries, including some Israeli entities from the first wave. Nothing destructive was seen in the second.

In the first wave the attackers went after Check Point Mobile Access gateways. They dropped PHP webshells into a directory the portal uses to build its login pages, which gave them a way to run commands. Then they deployed TSGA and TSProxy, variants of a malware framework called PhiliKit that has turned up before in China-linked UNC5221's intrusion into Ivanti products, for backdoor access and to intercept network traffic. After that came internal asset discovery, a move to a VMware ESXi host, a wiper, and a note naming Dream Security.

The second wave hit Check Point Security Gateways more broadly. Check Point says neither wave showed a clear sector preference, which it reads as opportunistic initial access rather than targeting by industry.

How the chain works

The PHP bugs are the way in. Both are memory-handling faults in PHP itself: one involves the way PHP aborts a request on out-of-memory errors, leaving request memory in an uninitialized state that cleanup later reads or branches on; the other involves global state that can keep pointing at request memory after it has been freed. The PHP project's descriptions say multiple strategies can trigger either condition and reach remote code execution, without authentication.

Getting code running as the web service user isn't root. That's where CVE-2026-123039 comes in, a local privilege escalation in Check Point's Gaia OS DynamicCLI daemon, rated 7.8 under CVSS 3.1 by Check Point. The daemon runs as root and listens on a world-writable local socket, /tmp/dynamic_socket, without authenticating the processes that connect. An authenticated local user can send it a command and have it run as root. Affected builds listed by Check Point are R82.10 with Jumbo Hotfix Take 50 or below, R82.20 with Take 10 or below, R82 with Take 130 or below, and R81.20 with Take 173 or below, for both Quantum Security Gateway and Quantum Security Management.

So the chain is: unauthenticated RCE in PHP, a foothold on the appliance, then a local escalation to root. From root, webshells, backdoors and a wiper are all within reach.

HackZoneLabs assessment

The interesting part for defenders isn't the PHP bugs on their own. Those are patched, and anyone running PHP 8.2, 8.3, 8.4 or 8.5 below the fixed releases has a separate, more general problem. What matters here is the second step: a root-running daemon on a security appliance that trusts anything able to write to a local socket. That turns "we got a shell as the web user" into "we own the box", and on a gateway that means the device guarding the perimeter is now the thing inside it.

We'd treat the wiper as the part to plan around. A wiped ESXi host is a recovery problem, not just a containment one, and the report gives no indication that the attackers needed anything exotic to get there once they had root.

On attribution, Check Point is unusually careful and we'd match that caution. The operators worked during typical Chinese working hours and used China-linked malware and infrastructure, but Check Point says the destructive outcome doesn't fit known Chinese operations, and that the evidence doesn't let it assess the operation's true nature with high confidence. It lists several live possibilities: one actor ran the whole campaign, the actor was only an initial access broker, or it was a false-flag operation. It also floats the wiper as a smoke screen. The note naming Dream Security is a claim left at the scene, not proof of who was there. Dream, for its part, has linked PHP2Shell attacks on Palo Alto Networks firewalls to Chinese hackers, which is a separate campaign and doesn't settle this one.

What remains unknown

Nobody has published how many organizations were hit in either wave, and the report gives no figure. Check Point doesn't say how the PHP2Shell access was obtained in each case, whether the affected gateways were internet-facing, or how long the intruders sat inside before the wiper ran. The patch status of CVE-2026-123039 isn't stated in the material we have; Check Point's advisory is the place to check, along with the hotfix take levels above.

For defenders, the order we'd work in: confirm PHP is on a fixed release wherever it's exposed, then check Check Point gateway and management builds against the hotfix takes listed, then look for PHP files sitting in the Mobile Access portal's login-page directory. Webshells there are the specific artifact this campaign left behind. After that, the usual post-compromise questions apply to any gateway that was reachable: what ran as root, and what else on the network could be reached from it.

CVE references

CVE-2026-109618

CVE-2026-109619

CVE-2026-123039