Attackers Exploited Check Point Gateways to Gain Root and Deploy an ESXi Wiper, Company Says

Check Point published findings on Thursday, Nov. 12 describing a two-wave campaign against its own Security Gateways. The attackers got in through the Mobile Access portal, took root on the appliance, and in at least one case reached into a VMware ESXi host to destroy files.

The targets were unpatched gateways.

Two waves, one entry chain

The first wave began Oct. 30, 2026, and went after Israeli organizations. Check Point said the activity came from the IP address 130.94.19[.]204 and started about a week after a security fix became available. Some of those intrusions were successful and included destructive activity.

The second wave came on Nov. 2. It reached organizations across multiple countries and sectors, and some Israeli victims from the first wave were hit again. Check Point found no evidence of destructive activity in that wave and no particular geographic or industry focus.

The attackers used PHP2Shell exploitation tied to CVE-2026-109618 and CVE-2026-109619 to get a foothold through the portal. From the portal service account, they escalated to root using CVE-2026-123039.

The privilege escalation bug

CVE-2026-123039 carries a CVSS score of 7.8. It is a missing authorization flaw in the DynamicCLI interface of Gaia OS, the operating system on the gateways.

The dynamic_server process runs as root and takes commands through a socket at /tmp/dynamic_socket. Every local user has permission to write to that socket, and the service does not check who sent a command. Any authenticated local user can run arbitrary commands as root by writing a single request.

"The issue is a local privilege escalation and requires the attacker to already have local code execution on the appliance," Check Point said. The company added that it observed active exploitation against "a couple of dozen customers."

Affected versions are R82.20, R82.10, R82, R81.20, R81.10 and R81.

Backdoor, then the wiper

With root, the attackers dropped PHP web shells in the portal's template directory. The expanded web shell ran system commands, executed PHP, and accepted file uploads protected by a hardcoded key.

Then came TSGA, a persistent Linux backdoor running as slot_CPconfigdaemon. Its embedded networking component, TSProxy, was written to /lib/libcpfwcommon.so and loaded into appliance processes. Check Point said TSProxy intercepts networking functions to handle specially marked attacker connections while ordinary traffic keeps flowing. That lets hostile sessions ride existing services unnoticed.

In the investigated intrusion, the attackers used a scanner called Gogo to map internal systems. They then connected to a VMware ESXi host over SSH using the vpxuser service account and ran a wiper called destroy_v6.

The wiper walks target directories, normally overwrites files with zeros, and deletes them. A fast mode skips the overwriting. It left behind notes named DREAM_ANNEXATION.txt, which carried political themes and rejected ransom negotiations.

Who did this is not settled

Check Point found that TSGA and TSProxy are modified variants of PhiliKit, a malware framework previously documented in attacks exploiting Ivanti vulnerabilities. The tools share distinctive code, configuration and cryptographic material with it. ESET has associated PhiliKit with the China-nexus group UNC5221.

Check Point stops well short of naming anyone. Its researchers said the evidence "does not allow us to assess with high confidence the true nature of this operation." Several scenarios remain plausible, the company said: the identified actor ran the whole campaign, acted only as an initial access broker, or took part in a false-flag operation. The destructive activity could also have been a smoke screen.

The notes left during the wiping used the Dream Security brand. Dream had recently published research on PHP2Shell exploitation of Palo Alto Networks devices by China-nexus actors. Check Point said the timing raises the possibility of retaliation, but the available evidence does not establish a clear motive.

Tool reuse is cheap, and a branded note proves nothing about who typed the commands.

What is established

The sequence of events is documented by the vendor that makes the product. The first-stage flaws got attackers in. A second flaw gave them root. A backdoor kept them there. In at least one case, an adjacent virtualization host was wiped.

Check Point has not said how many organizations lost data. It put the count of customers hit by the privilege escalation exploit at a couple of dozen. It has not named any victim.

The local privilege escalation bug is not a remote entry point on its own. The attacker had to be on the box first. That puts the weight on the earlier portal flaws and on how quickly customers applied the fix, which was available about a week before the first wave began.

Whether the second wave's access is now being held for later use is an open question. Check Point found no destruction in those intrusions, but its own description of TSGA, which persists through backups and snapshots and tampers with binary firewall logs, shows what a quiet foothold on these gateways allows.