Attackers have combined a newly disclosed Check Point root-escalation zero-day with the PHP2Shell flaws to take over Security Gateways, plant a stealthy backdoor and, in some Israeli networks, wipe data on VMware ESXi hosts. Any UK organisation running an internet-facing Mobile Access portal should treat this as a patch-and-hunt job this weekend.
What happened
Check Point’s research team published an investigation on 12 November 2026 into a campaign against unpatched Check Point Security Gateways. The intruder first got in through the Mobile Access web portal using the PHP2Shell flaws we reported in October, then escalated to root with a previously unreported weakness in the gateway’s DynamicCLI interface. That bug is now tracked as CVE-2026-123039.
The activity came in two waves. The first, beginning on 30 October, focused on Israeli organisations, and in some of those cases the attacker went on to destroy data. A second scanning wave on 2 November revisited some of the same Israeli targets but also reached organisations in several other countries, with no obvious sector preference. Check Point says that wave showed no destructive behaviour, though it is unclear what the attacker did with any access gained. According to Check Point’s advisory, quoted by The Hacker News, it saw the zero-day actively exploited “against a couple of dozen customers”.
The timing should worry anyone who patches on a monthly cycle. Check Point notes that the first wave landed roughly a week after a security fix became available.
The technical picture
CVE-2026-123039 carries a CVSS score of 7.8. It is a missing authorisation check in the DynamicCLI inter-process communication socket: a local user who can reach that socket can have commands executed as root. On its own that requires the attacker to already be running code on the box, which is exactly what PHP2Shell provided through the portal’s service account. Chained together, the two give an unauthenticated outsider full control of a perimeter firewall.
Check Point lists affected versions as R81, R81.10, R81.20, R82, R82.10 and R82.20 of Force Firewalls, Management and Log Servers, Multi-Domain Security Management, Multi-Domain Log Server and Maestro Orchestrator.
Once root, the attacker dropped PHP webshells into the template directory the Mobile Access portal uses to build its login pages, giving a web-based command channel protected by a hardcoded key. They then moved to something more durable: TSGA, a passive Linux implant that renames itself slot_CPconfigdaemon and persists across reboots. Check Point describes TSGA as built specifically for its appliances, with encrypted remote access, theft of gateway configuration, survival through backups and snapshots, process injection and the ability to tamper with binary firewall logs.
TSGA carries a second component, TSProxy, written to disk as a shared library and injected into chosen appliance processes. It hooks networking functions so that specially marked attacker connections are diverted to the implant while normal traffic flows as usual.
In the Israeli intrusions the attacker used the open-source gogo scanner from the gateway to map internal systems, then authenticated over SSH to a VMware ESXi host using the vpxuser service account. There they ran a Linux wiper called destroy_v6, which walks a target directory, tries to zero-fill files and then deletes them, with an optional fast mode that skips the overwrite. Each directory received a politically themed note, DREAM_ANNEXATION.txt, which refers to Dream Security and rules out any ransom negotiation.
Attribution is deliberately cautious. TSGA and TSProxy share code, credentials and even a TLS certificate with PhiliKit, a toolkit ESET documented in June 2026 against Ivanti appliances and tied to the China-nexus cluster UNC5221. LightNode hosting and scanning during Chinese working hours point the same way, but the Israel focus and Hebrew note do not fit, and Check Point openly considers an access broker, a false flag or a destructive smokescreen.
Why it matters for UK organisations
No UK victims have been named, and the destructive wave targeted Israel. That is not a reason to relax. The second wave was opportunistic and global, Check Point gateways are widely used by British organisations, and Mobile Access is exactly the sort of remote-access portal that gets left on the internet for years.
The bigger lesson is about where the damage lands. A compromised firewall is not just a lost device: it sits on trusted paths into the server estate, holds configuration that maps the network, and in this case was used as a launch pad to a hypervisor. Wipe an ESXi host and you can lose dozens of virtual machines at once. For organisations in scope of NIS, or preparing for the Cyber Security and Resilience Bill, this is precisely the kind of incident reporting duties are written for.
Expert view
This campaign is the edge-device problem in miniature. A widely publicised flaw in a common runtime turned up inside a security appliance, it is easy to assume a vendor’s own stack is insulated, and a week was enough to prove otherwise. When we test perimeter estates, the gateways and VPN concentrators are routinely the least monitored systems in the building, not least because nobody can install an EDR agent on them.
The log-tampering capability in TSGA deserves particular attention. If your main source of truth about perimeter traffic is the firewall’s own log, a root-level implant on that firewall can quietly edit history. In my experience, the organisations that catch this kind of intrusion are the ones that ship logs off the appliance in near real time and alert on gaps, not just on content.
I would also flag the vpxuser pivot. ESXi management accounts and SSH access from network appliances to hypervisors should almost never be legitimate.
What to do now
- Patch immediately. Install the November Jumbo Hotfix on every Security Gateway and Management Server, starting with gateways that expose Mobile Access to the internet. This maps directly to the Cyber Essentials security update management control.
- Reduce exposure. If Mobile Access is not needed, disable it. If it is, restrict who can reach the portal where practical (Cyber Essentials: firewalls and secure configuration).
- Hunt on previously exposed gateways. Check Point’s guidance, as reported by BleepingComputer, flags PHP session files carrying the upload_progress_pwn string, rogue CPconfigdaemon processes or binaries, and unexplained holes in firewall logging. Its research also describes webshells named zz*.tpl in the portal templates directory. Check for the published network indicators 130.94.19[.]204 and 130.94.19[.]168.
- Treat a hit as a full compromise. If indicators are present, assume configuration and credentials held on the gateway are stolen. Rebuild from known-good media rather than cleaning in place, and rotate VPN, admin and integration secrets.
- Lock down the hypervisor path. Block SSH from network appliances to ESXi hosts, review use of the vpxuser account, and alert on any such connection (Cyber Essentials: user access control).
- Protect recovery. Confirm you hold offline or immutable backups of virtual machines that a compromised ESXi host cannot reach, and test a restore.
Bottom line
An internet-facing portal, a known web flaw and a fresh root bug were enough to turn Check Point firewalls into a beachhead for wiping hypervisors. Patch the gateways, check them for the published indicators, and close the network path from your perimeter kit to your virtualisation layer before someone else tests it for you.
