THREATNOIR
Subscribe
Rapid alert3 min read

Check Point Gaia under attack: PHP2Shell chained to root for ESXi wiper, patch now

Attackers are chaining PHP2Shell (CVE-2026-109618/9) with a DynamicCLI root flaw (CVE-2026-123039) on Check Point Mobile Access gateways, then wiping VMware ESXi hosts. Patch and hunt tonight.

Marcus Lenngren
Marcus Lenngren
Founder, ThreatNoir
Share this alert LinkedIn X Bluesky Reddit Email

Check Point Gaia rapid alert: Mobile Access portal exposed? One chain and your ESXi is wiped.
The rapid alert card: save it and share it with your team

What happened

Attackers are breaking into Check Point Security Gateways through their Mobile Access portals, then escalating to root and, in some cases, destroying VMware ESXi hosts.

The entry point is PHP2Shell, two critical PHP remote code execution flaws tracked as CVE-2026-109618 and CVE-2026-109619 that affect all PHP versions from PHP 5 onwards. These were patched upstream on 21 Oct. Attackers reach the portal service account, then exploit CVE-2026-123039, a local privilege escalation in the Gaia OS DynamicCLI interface rated 7.8.

The DynamicCLI daemon (dynamic_server) runs as root and listens on a world-writable local socket, /tmp/dynamic_socket, without authenticating the connecting process. Any local user can send a command and have it run as root. This is not a standalone remote flaw: prior access is required, which the PHP2Shell step provides.

After gaining root, attackers plant PHP webshells in the portal template directory, install the TSGA backdoor (running as slot_CPconfigdaemon) and its embedded TSProxy component written to /lib/libcpfwcommon.so. They used the gogo scanner to find internal systems, then pivoted to a VMware ESXi host over SSH using the vpxuser account and ran the destroy_v6 wiper, leaving DREAM_ANNEXATION.txt notes.

TSGA and TSProxy share code and cryptographic material with PhiliKit, previously linked to China nexus UNC5221. Check Point says the evidence does not allow a high-confidence attribution, and lists tool reuse, access brokering and false flag as plausible.

Timeline

  • 21 Oct: PHP2Shell patched upstream.
  • 30 Oct: Wave one, against Israeli organisations, with destructive activity against some.
  • 2 Nov: Wave two, worldwide and across sectors, no evidence of data destruction.
  • 12 Nov: Check Point Research publishes its analysis.
  • 13 Nov: Check Point releases emergency hotfixes.

Am I affected?

Check Point lists affected releases from R81 through R82.20, including Firewall, Security Gateway, Multi-Domain Security Management Server, Security Management Server, Scalable Platforms, logging and Maestro products. Spark Firewalls and Smart-1 Cloud are not affected.

You are most exposed if you run a Mobile Access portal reachable from the internet. Check Point confirmed active exploitation against about two dozen customers. Neither wave showed a clear sector focus, so treat this as opportunistic.

What to do now

  1. Apply the fixed Jumbo Hotfix for your train: R82.20 Take 14, R82.10 Take 52, R82 Take 132, or R81.20 Take 174.
  2. If you cannot patch immediately, stop the dynamic_server process and prevent it from restarting. Note this disables Dynamic CLI commands.
  3. Confirm the socket is fixed: /tmp/dynamic_socket should show permissions 0660, owned by root config, not 0777.
  4. Pull and check against Check Point's published IOCs.
  5. If you find signs of compromise, treat any connected ESXi hosts as at risk and check vpxuser SSH access and backups immediately.

How to hunt

  • Examine /var/log/dynamicCli.log for commands that do not use the default Clish wrapper and for the system() sink, which is uncommon or absent in legitimate traffic.
  • Look in the portal template directory for .tpl files matching zz*.tpl, and for a challenge_render.tpl you did not create.
  • Check /opt/CPcvpn-R81.20/tmp/ for PHP session files containing the upload_progress_pwn marker.
  • Look for hundreds of Apache/PHP worker segmentation faults during late October.
  • Check for /tmp/CPconfigdaemon, slot_CPconfigdaemon in the boot persistence directory, /lib/libcpfwcommon.so, /tmp/.bd.log and /tmp/.up.tpl.
  • On ESXi, look for /tmp/des wiper and DREAM_ANNEXATION.txt notes.

What does not help

Rejected connection logs show blocked attempts, not proof that an earlier compromise was prevented. Do not treat them as an all-clear. Hunt for the webshells, TSGA and the socket permissions directly.

Sources

Pass this alert on LinkedIn X Bluesky Reddit Email

Drafted with the help of AI, then checked, edited and approved by Marcus Lenngren, who takes editorial responsibility for it.

More from us