Attackers are chaining PHP2Shell with a local privilege escalation vulnerability in Check Point Gaia OS to gain root access on unpatched Check Point Security Gateways. Check Point Research traced one intrusion from an internet-facing Mobile Access portal to a VMware ESXi host, where the attackers deployed a wiper. The first observed wave targeted Israeli organizations. A second wave reached organizations across multiple countries and sectors.
Check Point disclosed the Gaia flaw, CVE-2026-123039, on November 12. CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on November 13. Organizations with previously exposed Mobile Access gateways should apply the November Jumbo Hotfix and review those systems for signs of intrusion.
Vulnerability overview
| Field | Detail |
| CVE | CVE-2026-123039 |
| Severity | High, CVSS 3.1 score of 7.8 |
| Component | Gaia OS DynamicCLI daemon |
| Prerequisite | Local execution as a low-privileged user or service account |
| Impact | Command execution with root privileges |
| Exploitation | Confirmed by Check Point and listed in CISA KEV |
| Vendor advisory | Check Point SK1000362 |
The DynamicCLI daemon runs as root and accepts requests over a local socket accessible to unprivileged processes. The affected implementation fails to authenticate those requests, allowing a process with local access to execute commands as root.
In the observed campaign, PHP2Shell (CVE-2026-109618 and CVE-2026-109619) provided the remote entry point through the Mobile Access portal. The attackers then used CVE-2026-123039 to elevate from the portal service account to root.
Exploitation and campaign timeline
| Date | Development |
| October 23 | Check Point says an initial hotfix for PHP2Shell was available for affected gateways. |
| October 30 | The first observed wave targeted Israeli organizations with unpatched Mobile Access portals. Check Point documented destructive activity in a limited number of cases. |
| November 2 | A second wave targeted organizations across multiple countries and sectors, including some previously targeted in Israel. Check Point reported no evidence of destructive activity in this wave. |
| November 4 | Last exploitation activity recorded in the window described by Check Point’s advisory. |
| November 12–13 | Check Point published its advisory and campaign analysis on November 12. CISA added the Gaia flaw to KEV on November 13. |
After gaining root, the attackers placed PHP webshells in the Mobile Access portal’s template directory and installed the TSGA backdoor. Its embedded TSProxy component provided concealed access through existing appliance services. In the investigated destructive intrusion, the attackers scanned the internal network from the gateway, accessed a VMware ESXi host over SSH using the vpxuser service account, and deployed the destroy_v6 wiper. They left a note named DREAM_ANNEXATION.txt.
Check Point linked TSGA and TSProxy to PhiliKit, a malware family previously associated with the China-nexus cluster UNC5221. The shared tooling supports a connection at the malware level. Check Point said the available evidence leaves the operator behind the destructive phase and the campaign’s motive unresolved.
Affected products and fixed versions
Check Point identifies Gaia R82.20, R82.10, R82, and R81.20 as affected. CISA lists Security Gateways, Firewalls, Scalable Platforms, Security Management Servers, and Multi-Domain Security Management Servers. Check Point recommends installing its November Jumbo Hotfix on all affected Security Gateways and Management Servers, with internet-facing Mobile Access deployments first. Verify the installed Take for each system against its branch.
| Gaia branch | November Jumbo Hotfix Take containing the fix |
| R82.20 | Take 14 |
| R82.10 | Take 52 |
| R82 | Take 132 |
| R81.20 | Take 174 |
Indicators and hunting guidance
| Signal | What to look for |
| Scanning and reconnaissance | 130.94.19[.]204 and 130.94.19[.]168 in perimeter or portal logs. Correlate with host or network activity before treating a source-IP match as evidence of compromise. |
| Portal exploitation | PHP session files containing upload_progress_pwn, especially alongside repeated Apache or PHP worker crashes. Check for unexpected zz*.tpl or challenge_render.tpl files in Mobile Access portal templates. |
| Gateway persistence | Unexpected CPconfigdaemon or slot_CPconfigdaemon files or processes, or the shared library /lib/libcpfwcommon.so. Compare suspicious artifacts against the published hashes. |
| Visibility gaps | Unexplained gaps in firewall traffic logs, especially after a logging daemon crash. Cross-check against upstream firewall, SIEM, or network telemetry. |
| Downstream activity | Unexpected SSH from a gateway to ESXi, unusual vpxuser authentication, evidence of destroy_v6, or files named DREAM_ANNEXATION.txt. |
Start the retrospective hunt on October 30, the first observed date, and extend it through the present to look for persistent access. Prioritize appliances that were internet-reachable and unpatched during the campaign, including appliances that have since been updated. Check Point publishes SHA-256 hashes for the portal webshell, both observed TSGA filenames, and the wiper in its research report.
Mitigation and incident response
- Patch the gateway and management estate. Inventory relevant Gaia branches, confirm the installed Hotfix Take, and apply a vendor-supported fixed build. Prioritize internet-facing Mobile Access. If an exposed gateway cannot be patched promptly, restrict external access to the portal until a fixed build can be deployed.
- Collect evidence from the gateway and independent sources. Preserve portal and appliance logs, relevant configuration records, and suspicious files. Correlate them with central network telemetry and ESXi or vCenter authentication records. Prioritize unexpected outbound connections from the gateway to management networks.
- Contain suspected root compromise and assess downstream exposure. Isolate or fail over affected gateways as operationally feasible. Coordinate recovery with Check Point Support, rebuild or restore from a known-good state, and rotate credentials or other secrets that may have been accessible from the appliance. Investigate ESXi and other internal systems reachable from the gateway before returning it to service. Updating the appliance closes the vulnerability while the investigation determines the scope of existing access.
If you suspect compromise, contact OP Innovate’s Incident Response team immediately.
Stay Safe. Stay Secure.
OP Innovate Research Team
