Check Point Gateway PHP2Shell Campaign: Two Waves and a Destructive Chain

The Check Point Gateway PHP2Shell campaign struck unpatched Mobile Access portals in two waves beginning 30 October 2026. Check Point Research documented gateway compromise, local privilege escalation and destructive activity in some first-wave cases.

Gateway owners should apply the fixed DynamicCLI Jumbo Hotfix take for their supported branch and verify the running take. They must also follow Check Point’s PHP2Shell remediation for the initial access path; the DynamicCLI fix addresses a later stage of this chain. A cyber threat intelligence platform can help them compare the campaign report with their own gateway and host evidence.

Check Point Gateway PHP2Shell Campaign: Which Hotfix Take?

Check Point’s advisory identifies these first fixed Jumbo Hotfix Accumulator takes for CVE-2026-123039. Apply the appropriate take on each affected gateway, then verify it is installed rather than relying on a completed change ticket.

R81 and R81.10 are affected and end of support; the advisory gives no fixed take. Plan a supported upgrade and confirm vendor guidance before changing production gateways.

DynamicCLI also affects specified management and scalable products. Check Point lists Spark Firewalls and Smart-1 Cloud as unaffected by that flaw, without assessing PHP2Shell exposure.

How the Two Waves and Destructive Chain Unfolded

Check Point Research dates the first wave to 30 October, when attackers targeted Israeli organizations through vulnerable gateways. On 2 November, scanning expanded across countries and sectors, including some earlier targets. The researchers saw destructive activity in some first-wave cases, but found no evidence of it in the second wave.

The researchers associate initial access with the PHP2Shell family, which includes CVE-2026-109618 and CVE-2026-109619. They do not identify which individual PHP flaw triggered each gateway intrusion. Our PHP2Shell PHP RCE overview explains the two flaws separately.

After portal access, the attackers used CVE-2026-123039 in DynamicCLI to gain root privileges, according to Check Point Research. They then placed webshells, established a persistent gateway backdoor and used the gateway to discover internal systems. In the investigated destructive case, they moved to an ESXi host and deployed a wiper. This is an incident-response priority because a gateway can become a route into internal systems.

What Gateway Defenders Should Check Now

Start with exposure and patch state, then investigate the activity Check Point described. The order below is our defensive reading of its research and advisory, not a substitute for an incident-specific investigation.

Check Point says abnormal DynamicCLI commands may appear in its daemon log, while patched systems log rejected unauthorized calls. Its advisory also provides a socket-permission check for confirming the local fix. Keep those checks within your normal forensic workflow and preserve evidence before remediation.

Brandefense Blackhole counted 372 dark-chat posts naming CVE-2026-109618 and 290 naming CVE-2026-109619 from 14 August to 12 November 2026. These are separate, potentially overlapping counts of posts, not victims or verified attacks. The same period had two posts naming CVE-2026-123039.

The prepared GitHub search counted 808 public repositories naming CVE-2026-109618 and 747 naming CVE-2026-109619 as of 12 November 2026. Repository names do not establish working exploit code or exploitation of this campaign. Check Point’s observed intrusions, rather than these activity counts, support the incident assessment.

Check Point Research does not confidently attribute the operation or its motive. Its malware lineage analysis leaves several explanations open, so treat the destructive stage as observed behavior rather than proof of a particular actor. For broader PHP remediation steps, use our PHP2Shell defense guide.