PHP2Shell Used to Wipe Check Point Gateway Victims

Check Point reports that attackers used the PHP2Shell vulnerabilities to break into its Gateway appliances and, in one campaign, deploy a wiper against victims. SecurityWeek summarized the findings on November 13.

What changed

PHP2Shell is the name for CVE-2026-109618 and CVE-2026-109619, two critical remote code execution flaws in PHP that were patched on October 21. Exploitation began days before the patches and turned into mass exploitation soon after. We covered the federal patch deadline and the first exploitation reports earlier.

Per Check Point, the activity came in two waves:

• October 30: a destructive wave against Israeli organizations running Mobile Access gateways.
• November 2: a second wave against Security Gateways in several countries. No destructive activity was seen in this one.

In the first wave, attackers used PHP2Shell for initial access, then abused CVE-2026-123039, a local privilege escalation in the DynamicCLI process, to get root. They placed PHP web shells in a directory the Mobile Access portal uses to build login pages, installed backdoor and traffic-interception tooling, moved to a VMware ESXi host and ran a wiper. A note referencing Dream Security was left behind.

Who did it is unclear

The attackers worked during typical Chinese working hours and used malware previously tied to China-linked UNC5221. But Check Point says a wiper does not match known Chinese operations, and that the evidence does not support a high-confidence call. It lists several plausible scenarios: one actor ran everything, the actor was only an access broker, a false flag, or the destruction was a smoke screen. Neither wave showed a clear sector preference.

What to do first

1. Patch PHP everywhere it faces the internet, including appliances and bundled components. Vendor guidance applies here, not our guess.
2. Check gateway appliances for unexpected files in web-served directories, especially login-page assets on Mobile Access portals.
3. Treat a gateway hit as a domain problem. The attackers went from the gateway to a hypervisor. Review ESXi host access from gateway segments and confirm you have offline, tested backups.
4. Apply Check Point’s own indicators and fixes. Use the vendor’s published guidance for CVE-2026-123039, which this write-up cites only through SecurityWeek.

Priority call

If you run Check Point gateways with PHP-based portals, this is above routine patching. The destructive wave was limited to the first set of victims, but the second wave used the same entry path against a broader group. Related coverage: Check Point management server zero-day.