Check Point gateways have been compromised in a two-wave PHP2Shell campaign that led to destructive attacks against reachable VMware ESXi hosts. The intrusions combined remote code execution, local privilege escalation, persistent backdoors and lateral movement from an internet-facing security appliance.
Check Point Research disclosed the campaign on 12 November 2026, after investigating attacks that began on 30 October. Although destructive activity was limited to some incidents in the first wave, exploitation of the underlying PHP2Shell flaws is confirmed in the wild.
How Check Point gateways were compromised
The unidentified attacker initially targeted internet-exposed Check Point Security Gateways through the Mobile Access portal. Two PHP vulnerabilities, CVE-2026-109618 and CVE-2026-109619, provided unauthenticated remote code execution and are collectively known as PHP2Shell.
These flaws enabled the attacker to execute commands within the portal service context without first obtaining valid credentials. The attacker then placed PHP webshells on compromised Check Point gateways, creating a route for continued command execution after the initial exploit.
Escalation from portal access to root
Initial access did not give the attacker complete control of the underlying appliance. To obtain it, the actor exploited CVE-2026-123039, a previously undisclosed local privilege escalation vulnerability affecting the DynamicCLI inter-process communication interface in Check Point Gaia OS.
Successful exploitation elevated the actor from the restricted portal service account to root. This gave the attacker extensive control over the gateway, including the ability to install additional tools, inspect internal connectivity and use the appliance as a trusted position for reaching other systems.
The actor installed a Linux backdoor named TSGA alongside an embedded networking component called TSProxy. Check Point assesses both components as modified variants of the PhiliKit framework. PHP webshells were also used to maintain access and execute further commands.
Media reporting on the investigation also identified use of the open source gogo scanner for internal asset discovery. This discovery stage helped the attacker identify systems accessible from the compromised gateway, including virtualisation infrastructure.
Check Point gateways became a route to ESXi
After compromising Check Point gateways and gaining root privileges, the attacker moved laterally to VMware ESXi hosts over SSH. The connection originated from the gateway, allowing the actor to take advantage of its internal network position.
No VMware ESXi vulnerability was identified or claimed in this campaign. Instead, the intrusion demonstrates how control of a perimeter security appliance can provide a route towards internal management interfaces when network access and usable credentials are available.
Deployment of the destroy_v6 wiper
On reachable ESXi hosts, the attacker staged and executed a Linux wiper named destroy_v6. The malware recursively deleted data and could overwrite content with zeroes before deletion, increasing the difficulty of recovering affected files and virtual machine assets.
In observed destructive incidents, the attacker also created a note named DREAM_ANNEXATION.txt. The note rejected ransom negotiations, reinforcing the assessment that the objective was destruction rather than conventional ransomware extortion.
Compromising an ESXi host can affect multiple virtual servers at once because its storage may contain numerous business systems. In this case, the destructive outcome followed a chain that began at the external gateway rather than with exploitation of the hypervisor itself.
Two attack waves had different outcomes
Check Point identified two distinct waves. The first began on 30 October 2026 and targeted Israeli organisations. Some victims in this wave suffered destructive VMware ESXi wiping after attackers moved from compromised Check Point gateways into the internal environment.
A second wave began on 2 November and targeted organisations across multiple countries and sectors. Check Point reported no destructive activity in this later wave, although the same broader combination of gateway exploitation and post-compromise tooling created a serious risk.
The known timeline is:
- 21 October 2026: The PHP project released fixed versions addressing CVE-2026-109618 and CVE-2026-109619.
- 23 October 2026: Check Point published mitigations and a hotfix process for PHP2Shell exposure on its gateways.
- 26 October 2026: CISA added both PHP2Shell vulnerabilities to its Known Exploited Vulnerabilities catalogue.
- 30 October 2026: The first attack wave targeted Israeli organisations and included destructive ESXi wiping.
- 2 November 2026: A second, international wave began, with no destructive activity observed by Check Point.
- 12 November 2026: Check Point Research published its analysis of the campaign.
- 13 November 2026: Multiple security publications reported the findings and their wider implications.
Affected Check Point products and features
The PHP2Shell exposure affects Check Point Security Gateways with PHP-backed web interfaces. Relevant features include the Mobile Access portal, Remote Access VPN with SSL Network Extender, Remote Access VPN with SAML realm authentication, Identity Awareness Captive Portal, UserCheck Portal and Zero Phishing.
Affected releases include R80 through R82.20 and Spark Firewall product lines listed in Check Point’s advisory. Check Point Management Servers and Log Servers are not affected. The vendor also states that R82.20 has self-protection through IPS signatures.
CVE-2026-123039 separately affects the Gaia OS DynamicCLI component. Exploitation of this privilege escalation vulnerability was observed on Security Gateways during the campaign, so addressing PHP2Shell alone is not sufficient when assessing potentially exposed appliances.
Exploitation status and attribution
Exploitation is confirmed. Check Point observed two attack waves between 30 October and 2 November, while CISA’s addition of both PHP2Shell vulnerabilities to its catalogue confirms broader active exploitation risk.
The actor remains unidentified. TSGA and TSProxy contain code overlap with PhiliKit, which has previously been associated with a China-linked threat group, but Check Point said the evidence does not support high-confidence attribution. Possible explanations include reused tooling, a false flag or activity involving an initial access broker.
Checks organisations should prioritise
Organisations operating exposed Check Point gateways should apply the vendor’s PHP2Shell hotfix and the fix for CVE-2026-123039. Where immediate patching is not possible, Check Point provides a temporary Apache configuration mitigation that denies multipart requests to reduce exploitability.
Incident reviews should look beyond the gateway because the observed chain progressed into internal virtualisation infrastructure. Priority checks include:
- Search for connections involving the observed source address 130.94.19.204.
- Look for PHP webshells, TSGA, TSProxy and unexpected root-level activity on Gaia OS.
- Review SSH sessions from gateways to VMware ESXi management interfaces.
- Search ESXi systems for destroy_v6 and DREAM_ANNEXATION.txt.
- Confirm that gateway portals are exposed only where operationally required.
If indicators are found, affected gateways and reachable ESXi hosts should be isolated and investigated together. The campaign shows that restoring or patching the perimeter appliance without checking systems accessible from it may leave destructive activity undiscovered.
Originally reported by BleepingComputer.
