Check Point Zero-Day Lets Attackers Take Root — and One Case Ended in a Wipe

Check Point spent this week notifying customers that someone had turned its own gateways
against them. The flaw at the centre of it, Check Point zero-day CVE-2026-123039, lets a local user
execute commands as root on unpatched firewall and management appliances.

It was exploited before a fix was public, and in a small number of cases the intrusion ended
with the network wiped. The flaw on its own is not the dangerous part; the chain is.

What this covers:

• What the Check Point zero-day actually does
• How the Check Point zero-day chain reached root
• Who was hit, and what was wiped
• Which Check Point zero-day versions are affected
• The fix and the Check Point zero-day mitigation
• The attribution question
• Check Point zero-day: what we recommend
• Check Point zero-day questions

What the Check Point zero-day Actually Does

The DynamicCLI daemon on Gaia OS runs as root. According to the CVE record it listens on a
world-writable local socket at /tmp/dynamic_socket and does not authenticate the
processes that connect to it.

Any authenticated local user who can write to that socket can send a command and have it
execute as root. Check Point scores it 7.8 under CVSS 3.1 with a local attack vector, and
classifies the weakness as incorrect permission assignment and missing authorization.

The nuance that matters: this is a local privilege escalation, not remote code execution. It
does nothing on its own. It needs someone already on the box with an account, which is exactly
why the attackers brought a way in.

How the Check Point zero-day Chain Reached Root

Initial access came through PHP2Shell, tracked separately as CVE-2026-109618 and
CVE-2026-109619. That is unauthenticated remote code execution in the Mobile Access portal,
scored 9.2. A fix shipped on October 23. The campaign began on October 30.

From there, in Check Point Research’s account: PHP2Shell for access, the DynamicCLI
escalation for root, PHP webshells, then the TSGA backdoor with its embedded TSProxy networking
component.

The operators then pivoted from the gateway to a VMware ESXi host over SSH and deployed a
wiper named destroy_v6, leaving a note titled DREAM_ANNEXATION.txt on the systems
they destroyed.

Two things make this worse than a typical edge-device compromise. The entry point was a patch
that had been available for a week. And the attackers did not stop at the firewall: an appliance
that fronts everything is a step, not a destination.

Who Was Hit, and What Was Wiped

Check Point describes two waves. The first, on October 30, targeted Israeli organizations and
included destructive activity against some of them.

The second, on November 2, targeted organizations across multiple countries and sectors, with
no destructive activity observed in that wave. The Check Point zero-day exploitation was still active as
of November 4.

Scope was a couple of dozen unpatched systems in a single region. Check Point says it notified
affected customers in real time and worked the incidents through its response teams. A small
number is good news for everyone else and cold comfort for the organizations whose storage was
wiped.

Dealing with this at your office? Talk to a local IT expert →

Which Check Point zero-day Versions Are Affected

Per the CVE record, Quantum Security Gateway and Quantum Security Management are affected at
these hotfix levels and below:

• R81.20 — Jumbo Hotfix Take 173 or below
• R82 — Jumbo Hotfix Take 130 or below
• R82.10 — Jumbo Hotfix Take 50 or below
• R82.20 — Jumbo Hotfix Take 10 or below

The product list covers Firewalls, Security Gateways, Security Management Servers,
Multi-Domain Security Management Servers and Scalable Platforms.

If you run any of them, the question is not whether you have one of these versions. It is
which take you are actually on, which is not always the number in the change log.

The Fix and the Check Point zero-day Mitigation

Check Point’s guidance is to install the November Jumbo Hotfix on all Management Servers
and Security Gateways as soon as operationally possible.

That release also carries the PHP2Shell fixes and treatments related to Node2Shell. We covered
the latter when CISA added it to the exploited-vulnerabilities catalog, and it is worth reading
alongside this one: the Node2Shell flaw in the same hotfix cycle.

For teams that cannot patch immediately, the interim step Check Point offers is to stop the
dynamic_server process and prevent it from restarting. That closes the escalation
path and does nothing about the access path, so it buys time rather than safety.

On the hunting side, the company points investigators at commands associated with known
exploitation attempts, any use of the system() sink, and commands that did not go
through the default Clish wrapper. That last one indicates execution as root through the socket
and deserves a closer look.

The Attribution Question

The tooling is familiar to anyone tracking appliance intrusions. TSGA and TSProxy are modified
variants of a framework called PhiliKit, previously documented in attacks against Ivanti gear.
ESET has associated PhiliKit with a China-nexus group tracked as UNC5221.

Check Point declines to follow it that far. Its researchers write that the evidence does not
allow a high-confidence assessment of the operation’s true nature.

They list the possibilities plainly: one actor ran everything, the actor was only an initial
access broker, or it was a false-flag operation.

They add that the destructive activity may have been a smoke screen rather than the objective.
The detail that feeds speculation is the note, which uses the Dream Security brand, and Dream
had recently published research on PHP2Shell exploitation of Palo Alto Networks devices by
China-nexus actors.

Check Point raises retaliation as a possibility and states that the evidence does not establish
a motive.

We are not going to name a culprit the researchers will not. What matters operationally is
that a perimeter appliance with an authentication gap in its local IPC layer is a
nation-state-grade entry point, whoever is holding the toolkit.

Check Point zero-day: What We Recommend

Treat this as two separate jobs, because the patch only closes one of them.

1. Establish actual hotfix takes on every gateway and management server, not
   the version number. Record them somewhere a person can read later.
2. Deploy the November Jumbo Hotfix to management servers and gateways,
   starting with anything internet-facing. The Mobile Access portals that started this are the
   ones exposed to the internet.
3. Hunt before you relax. A gateway reachable and unpatched between October 30
   and November 4 deserves the indicators Check Point published, particularly root-level command
   execution outside Clish.
4. Rebuild anything confirmed compromised. A rootkit on a perimeter device is
   not cleaned, it is replaced. Backdoors installed at that privilege survive a patch.
5. Shorten the window next time. A week between fix and exploitation is the
   entire lesson. Appliances on the internet need a patch cadence measured in days, which is the
   same reason we wrote about why edge appliances get scanned before you patch.

Nextek IT reviews perimeter appliance exposure, patch state and management-plane access for
South Florida businesses. If you are not sure which hotfix take your firewalls are running, that
inventory is the right first move.
Book a call with Nextek IT.

Check Point zero-day Questions

Can this be exploited over the internet directly? Not by itself. It requires
an authenticated local account. In these attacks that came from PHP2Shell, which is
unauthenticated remote code execution in the Mobile Access portal.

Does the PHP2Shell fix alone solve it? No. Patching PHP2Shell closes the way
in, but the escalation stays available to any local user until the November Jumbo Hotfix is
installed.

Is every Check Point customer affected? No. The affected list is specific
Quantum Security Gateway and Quantum Security Management builds at or below given hotfix takes.
Check the take numbers rather than assuming a version is safe.

How many organizations were compromised? Check Point describes a couple of
dozen unpatched systems in a single region, notified in real time, with destructive activity in a
limited number of cases.

Who is behind it? Unresolved. The tooling shares lineage with a framework ESET
tied to a China-nexus group, and Check Point says the evidence does not support a high-confidence
attribution, including a possible false-flag operation.

Sources:
Check Point Research’s exploitation
analysis, Check Point’s security
advisory, the CVE-2026-123039 record,
and BleepingComputer’s report.
Scores, versions and mitigation steps are as documented by Check Point and NIST.