Check Point says attackers chained PHP2Shell with a root flaw it first fixed on Nov. 12

Attackers entered unpatched Check Point Mobile Access portals through PHP2Shell, then took root. The October hotfix closes only the entry; the November Jumbo takes close both where Check Point has released them.

Rack-mounted security gateway with labels: PHP2Shell entry, root flaw first fixed Nov. 12, hotfix closes entry only

Check Point Research (CPR) says attackers used PHP2Shell on unpatched Mobile Access portals from Oct. 30, then took root through a second flaw that Check Point first fixed on Nov. 12. The October PHP2Shell hotfix closes only the entry; the November Jumbo takes close both, and late patchers need a hunt, not just a patch.

It is the appliance case our PHP2Shell piece warned about: PHP inside a product you cannot patch yourself.

What happened

CPR describes a first wave on Oct. 30 against Israeli organizations, some hit with destructive activity, and a broader second wave on Nov. 2 across several countries with no destructive activity seen. Check Point's blog says exploitation was observed until Nov. 4.

The chain: PHP2Shell on the Mobile Access portal, PHP webshells in the portal's template directory, escalation from the portal service account to root with CVE-2026-123039, a backdoor CPR calls TSGA that relaunches as slot_CPconfigdaemon, then SSH to a VMware ESXi host as vpxuser, the account vCenter uses to manage hosts. A note named DREAM_ANNEXATION.txt accompanied the destruction. CPR associates the activity with CVE-2026-109618 and CVE-2026-109619 without saying which was used.

CPR links the tools to PhiliKit, which ESET associates with China-nexus UNC5221, but says the evidence does not allow high-confidence attribution and "does not establish a clear motive."

Which update fixes which bug

Check Point's line that fixes were available a week before the attacks holds only for the Oct. 23 PHP2Shell hotfix in sk1000302. The root flaw had no fix while the attacks ran; sk1000362 says Check Point observed active exploitation against "a couple of dozen customers" and gives a mitigation (stop the dynamic_server process, which breaks Dynamic CLI commands).

The November Jumbo takes fix both bugs. sk1000362 names R82.20 Take 14, R82.10 Take 52, R82 Take 132 and R81.20 Take 174. Check Point's R81.20 Jumbo page still listed Take 173 as the latest on Nov. 13; until Take 174 appears, the root flaw on R81.20 has only the mitigation. R81.10 and R81 are end of support with no fixed take for the root flaw; they have only the mitigation and an upgrade. R81.10 did get the PHP2Shell hotfix, on Oct. 29.

Who is affected

Exploitation came through Mobile Access portals on R81.20 paths; that does not make other versions safe. sk1000302 also lists Remote Access VPN with SSL Network Extender or SAML, Identity Awareness Captive Portal, UserCheck and Zero Phishing; we read that as meaning a gateway running any of those features needs the PHP2Shell hotfix even without Mobile Access. The root flaw also affects Management and Log Servers, Multi-Domain and Maestro.

What to do now

  1. Patch owner, today: be on or above sk1000362's take, not CVE.org's version ranges, on every affected product. R81.20 Mobile Access gateways patched before Oct. 28 should confirm they have the hotfix re-released that day, on Jumbo Take 166 or higher.
  2. SOC, today: if an exposed portal ran without the PHP2Shell fix on or after Oct. 30, hunt rather than just patch. Look for zz*.tpl files in the portal template directory, slot_CPconfigdaemon, a listener on TCP 11072, traffic to 130.94.19[.]204 or 130.94.19[.]168, and commands in /var/log/dynamicCli.log that skip Check Point's wrapper. Hashes are in CPR's post. Check Point says no match does not rule out compromise.
  3. Network team, this week: if anything matches, we recommend rebuilding the gateway rather than restoring it. CPR says the backdoor persists in backups and snapshots and tampers with firewall logs, so log gaps are an indicator too.
  4. Identity team, this week: we would also rotate credentials the gateway held or that passed through the portal.
  5. Virtualization team, this week: we recommend blocking gateway routes to ESXi and vCenter management, turning off or restricting ESXi SSH, and reviewing hosts for vpxuser SSH logins that did not come from vCenter.

More in News

All in this topic