Exploits

Check Point Gateway: PHP2Shell to Root to Wiper

Eng. Donya Bino Published  ·  8 min read

Check Point published an incident report this week that reads like a chain-of-custody document, and the chain has five links. Initial access through PHP2Shell. Privilege escalation through a previously unreported Gaia OS flaw. A PHP web shell for persistence. A backdoor called TSGA with an embedded networking component. And on some victims, a wiper that deleted files and left a note behind.

The activity began on October 30, 2026, aimed at Israeli organizations. A second wave on November 2 widened to multiple countries and sectors.

Check Point is careful about attribution. More on that below, because the uncertainty is the most interesting part of the story.

The Chain, In Order

Stage

Component

What It Did

1. Initial access

PHP2Shell (CVE-2026-109618, CVE-2026-109619)

Reached vulnerable Mobile Access portals

2. Escalation

CVE-2026-123039

Moved from portal service account to root

3. Persistence

PHP web shells

Command execution and file upload

4. Backdoor

TSGA plus TSProxy

Encrypted remote access and concealed traffic

5. Destruction

destroy_v6 wiper

Recursive deletion, zero-overwrite, note dropped

Activity came from 130.94.19[.]204 and targeted vulnerable Mobile Access portals on Check Point Security Gateways. Check Point says the exploitation activity was consistent with PHP2Shell.

One timing detail matters. This began roughly one week after a security fix became available. The attackers were not early. They were fast on the unpatched population.

The New Flaw: CVE-2026-123039

This is the piece Check Point had not disclosed before.

CVE-2026-123039 is a missing authorization flaw in the DynamicCLI process, rated 7.8. It lets any authenticated local user run arbitrary commands by writing a single request to a socket, and that request escalates to root.

Check Point is precise about the precondition. The issue requires the attacker to already have local code execution on the appliance.

That precondition is why the PHP2Shell stage comes first. The portal service account is not root. CVE-2026-123039 is how it becomes root.

Check Point says it observed active exploitation of this flaw against "a couple of dozen customers." That is not a theoretical exploit. It has been used.

Affected Versions

The flaw impacts R82.20, R82.10, R82, R81.20, R81.10, and R81 across these products:

  • Check Point Force Firewalls
  • Check Point Management and Log Servers
  • Multi-Domain Security Management and Multi-Domain Log Server
  • Maestro Orchestrator

The Two Waves

  • Wave one, October 30, 2026. Israeli organizations, via vulnerable Mobile Access portals. Check Point found evidence of successful compromise in some cases. Some of these organizations were later hit with destructive actions, including wiper deployment.
  • Wave two, November 2, 2026. Some previously targeted Israeli organizations plus organizations worldwide, with no clear geographic or sector preference. Check Point reads that as an opportunistic initial-access effort rather than a curated target list.

That shift is worth noting. A targeted wave followed by a broad one suggests the operators had a working exploit and went looking for volume.

The Backdoor: TSGA and TSProxy

TSGA is the persistent piece. It deploys as slot_CPconfigdaemon, which is a masquerade dressed as a legitimate Check Point component.

Its capabilities, per Check Point:

  • Encrypted remote access
  • Configuration theft
  • Backup and snapshot persistence
  • Process injection
  • Binary firewall-log tampering

TSProxy is the embedded networking component, and its mechanism is worth understanding. The injection code loads a library into selected appliance processes. That library intercepts networking functions, handling specially marked attacker connections while letting ordinary traffic continue.

The result is a persistent standalone backdoor combined with concealed access through services the appliance already runs. Nothing new listens on a port. Nothing new appears in a connection table.

Other Post-Exploitation Activity

  • Deploying the gogo scanner on the gateway to discover internal assets and services
  • Moving laterally to a VMware ESXi host over SSH, authenticating with the vpxuser service account
  • Staging and executing destroy_v6, a Linux ELF wiper

The wiper's behavior is specific. It recursively traverses a target directory and deletes every file regardless of extension. It attempts to overwrite files with zeros before deleting them. And it drops a note named DREAM_ANNEXATION.txt in each processed directory.

The Attribution Puzzle

This is where the report gets genuinely interesting, because Check Point declines to give a clean answer.

TSGA and TSProxy are assessed to be Check Point-specific components of a toolkit called PhiliKit, first documented by ESET in June 2026 and attributed to a China-nexus espionage group tracked as Armory Castle, formerly UNC5221.

Two additional factors point in the same direction. The use of LightNode VPS infrastructure. And scanning activity concentrated between 12 and 9 a.m. UTC, which lines up with typical Chinese working hours.

Then Check Point explains why it stops short.

Evidence Pointing Toward China-Nexus

Evidence Pointing Away

Toolkit components match PhiliKit

Use of wiper malware

LightNode VPS infrastructure

Focus on Israel

Scanning during Chinese working hours

Explicit Israeli-Palestine references in the note

The contradiction is real. Espionage groups generally avoid destructive wipers, because destruction burns access that took months to build. And a note referencing the Israeli-Palestine conflict does not match a China-nexus espionage pattern.

Check Point lays out the possibilities without picking one. The identified actor ran the entire campaign. The identified actor served as an initial access broker only. The operation was a false flag. Or the destructive activity was a smoke screen for something else.

Their conclusion is honest. The evidence does not allow a high-confidence assessment of the true nature of the operation.

What Defenders Should Do

  • Patch CVE-2026-123039 on every listed product. Force Firewalls, Management and Log Servers, MDS and MDLS, Maestro Orchestrator. The fix exists.
  • Patch PHP2Shell if you have not. The chain starts there. If the gateways are patched for the runtime flaws, the escalation has no entry point.
  • Hunt for slot_CPconfigdaemon. That is the masquerade name TSGA deploys under. Compare against your known-good appliance inventory.
  • Look for destroy_v6 and DREAM_ANNEXATION.txt. Both are specific and searchable. If either appears anywhere on a network, treat it as an active destructive event.
  • Check ESXi access logs for vpxuser activity that does not match your virtualization management baseline. That is the lateral movement path.
  • Block 130.94.19[.]204.
  • Review Mobile Access portal exposure. That is the entry vector. If the portal does not need to face the internet, take it off.
  • Watch for the gogo scanner. Internal asset discovery from a gateway is not normal appliance behavior.
  • Look for firewall log tampering. TSGA can modify binary firewall logs, which means gaps in your own record of what happened.

The Lesson in the Chain

None of the five stages is novel on its own. PHP2Shell has been documented. Local privilege escalation through a socket interface is a familiar pattern. Web shells and backdoors are standard. Wipers are standard.

What is notable is the assembly. Someone took published runtime flaws, found an undisclosed escalation path, built Check Point-specific persistence, and then in some cases burned it all with a wiper.

Whether that was one actor, a broker handing off to a client, or something more complicated is exactly the question Check Point declined to answer. And in this case, the refusal is more useful than a confident guess would have been.

FAQ

What is PHP2Shell?

Two memory-safety flaws in the PHP runtime, CVE-2026-109618 and CVE-2026-109619, that chain into unauthenticated remote code execution on affected Apache mod_php builds. In this campaign it provided initial access.

What is CVE-2026-123039?

A missing authorization flaw in the DynamicCLI process of Gaia OS, rated 7.8. It lets any authenticated local user run arbitrary commands by writing a single request to a socket, escalating to root. It requires the attacker to already have local code execution.

Which products and versions are affected?

R82.20, R82.10, R82, R81.20, R81.10, and R81 across Check Point Force Firewalls, Management and Log Servers, Multi-Domain Security Management and Multi-Domain Log Server, and Maestro Orchestrator.

What is TSGA?

A Linux gateway implant with Check Point-specific functionality, deployed as slot_CPconfigdaemon. It provides encrypted remote access, configuration theft, backup and snapshot persistence, process injection, and binary firewall-log tampering.

What is TSProxy?

The embedded networking component of TSGA. It injects a library into selected appliance processes, intercepting networking functions to handle specially marked attacker connections while ordinary traffic continues.

What does the wiper do?

destroy_v6 recursively traverses a target directory, deletes every file regardless of extension, overwrites files with zeros before deletion, and drops a note named DREAM_ANNEXATION.txt in each processed directory.

Did the attackers reach anything beyond the gateway?

In at least some cases, they moved laterally to a VMware ESXi host over SSH using the vpxuser service account.

Who is behind it?

Check Point does not say with confidence. The toolkit components match PhiliKit, attributed to Armory Castle, a China-nexus group. But the wiper use, the Israel focus, and the note's political content contradict that pattern. Check Point lists four plausible scenarios, including a false flag.

What are the strongest indicators?

slot_CPconfigdaemon, destroy_v6, DREAM_ANNEXATION.txt, the IP 130.94.19[.]204, vpxuser SSH activity from a gateway, and the gogo scanner running on an appliance.

Was this exploitation widespread?

Check Point says it observed active exploitation of CVE-2026-123039 against a couple of dozen customers. The first wave targeted Israeli organizations, and the second wave was broader and opportunistic.

How fast did the attacks start after patching?

About one week after a security fix became available. The attackers were not early, they were fast on the unpatched population.

Source: The Hacker News
Professional Services

Explore Our Cybersecurity Services

Our insights are backed by hands-on service delivery. If your business needs professional cybersecurity support, our UK-based specialists are ready to help.

© 2016 – 2026 Red Secure Tech Ltd. Registered in England and Wales — Company No: 15581067