Check Point Patches Exploited Gaia OS Zero-Day That Gives Attackers Root on Firewalls and Management Servers

Check Point has released fixes for CVE-2026-123039, a local privilege escalation flaw in Gaia OS that attackers have used since about October 30 to turn a foothold on a Check Point appliance into full root access. According to Check Point's security advisory published November 12, the company saw exploitation against roughly two dozen customers. In those attacks, the intruders first got in through two PHP2Shell vulnerabilities (CVE-2026-109618 and CVE-2026-109619) in the Mobile Access portal. Some intrusions then led to webshells, backdoors, lateral movement, and destructive wiper activity against VMware ESXi hosts.

The CVSS score of 7.8 (High) can make this look like a fix that can wait for the next maintenance window. It should not wait. On its own, the flaw requires an attacker to already be running code on the box. In practice, attackers have been pairing it with an internet-facing entry point, and the result is a root shell on the device that sits between your network and the internet.

At a glance

Affected: Gaia OS on Check Point Force Firewalls, Management and Log Servers, Multi-Domain Security Management and Multi-Domain Log Servers, and Maestro Orchestrator, versions R82.20, R82.10, R82, R81.20, R81.10, and R81. Spark Firewalls and Smart-1 Cloud are not affected.

Do not skip management servers: they are on the affected list and need the same patching urgency as gateways.

What to do, in order:

Inventory every Check Point appliance and its version, and note which ones expose a Mobile Access portal to the internet.
Install the November Jumbo Hotfix Accumulator take for your version, starting with internet-facing gateways.
If you cannot patch right away, apply the temporary mitigation in sk1000362 and accept the loss of Dynamic CLI.
Hunt for indicators of compromise back to at least October 30.
Document what you found and what you did.

What the flaw actually is

The problem is in the Gaia OS DynamicCLI service. Per Check Point's support article sk1000362, a daemon called dynamic_server runs as root and listens on a socket at /tmp/dynamic_socket. On vulnerable systems that socket is world-writable (mode 0777), and the daemon does no authentication. Whatever commands it receives, it runs as root. Check Point classifies the issue under CWE-732 and CWE-862, which covers both the permission problem and the missing authorization check.

Put plainly, any local user or process on the appliance, no matter how low its privileges, can write to that socket and have its commands executed as root. That is why the flaw only matters once someone has code running on the device, and also why it matters so much once they do.

How the attack chain worked

The attacks Check Point observed did not start with this bug. They started with the PHP2Shell flaws in the Mobile Access portal, which gave attackers code execution on the gateway. From there, the attackers used the DynamicCLI socket to move from that limited foothold to root. According to the advisory, follow-on activity included webshell deployment, backdoors identified as TSGA and TSProxy, lateral movement, and in some cases wiper activity on VMware ESXi hosts. Check Point says it notified affected customers in real time.

One detail is worth noting for anyone who has been keeping up with Check Point patches. A hotfix for the PHP2Shell flaws has been available since October 23, according to sk1000362 and The Layman Security. Applying it closes the entry point used in the observed attacks, but it does not fix the privilege escalation. Any other path to local code execution on the appliance still leads to root until the November fix is installed.

Affected products and fixed versions

The fix is included in the November Jumbo Hotfix Accumulator, which also carries the PHP2Shell fix and addresses other issues, including CVE-2026-107484, per Check Point. The fixed takes listed in sk1000362 are:

Gaia version	Fixed in Jumbo Hotfix Accumulator
R82.20	Take 14 or later
R82.10	Take 52 or later
R82	Take 132 or later
R81.20	Take 174 or later
R81.10 and R81	Listed as affected, but no fixed take was identified in the material we reviewed. Check sk1000362 directly for the current remediation path, and use the temporary mitigation below in the meantime.

The affected product list covers more than gateways. Management and Log Servers, Multi-Domain servers, and Maestro Orchestrators are all included, a point that practitioners on X flagged as easy to miss. If your management server is patched on a different schedule from your gateways, it needs to be on this round too.

If you cannot patch tonight

Sk1000362 describes a temporary mitigation: stop the dynamic_server process and use dbset commands to keep it from restarting. Follow the exact steps in the support article rather than improvising them. The tradeoff is real. Disabling the daemon breaks Dynamic CLI commands (Check Point references sk144112 for that functionality), and CheckMates community discussions point out that impact while still recommending the Jumbo Hotfix as the priority. Treat the mitigation as a bridge to patching, not a substitute.

MSP Anthony Mongeluzo summed up the practical advice on X: gateway owners with Mobile Access enabled should install the November Jumbo Hotfix the same day, and anyone who cannot should stop dynamic_server per sk1000362 while reviewing portal logs back to October 30.

Hunting for signs of compromise

Patching stops future exploitation. It does not remove an attacker who is already on the box. If you run an internet-facing Mobile Access portal on an affected version, assume you need to look. Check Point's advisory and research blog list indicators to hunt for from October 30 onward, including:

Connections from the scanning IPs 130.94.19[.]204 and 130.94.19[.]168
PHP session files containing the string upload_progress_pwn
Processes masquerading as CPconfigdaemon
Wiper or scanner tooling in /tmp
Notes referencing "Dream Annexation"
Unexplained gaps in logs

Some reporting mentions scanning before October 30, so if your log retention allows it, look further back. The full IOC list and hunting guidance are in Check Point's research publication linked from the advisory. If you find a hit, treat the appliance and anything it can reach as part of an incident, not just a patching task. The ESXi wiper activity in some cases means hypervisors behind the gateway belong in scope.

Why this matters in health care environments

For many health care organizations, the perimeter firewall is also the remote access point for clinicians, the boundary in front of EHR and other clinical systems, and the enforcement point for whatever segmentation exists. Root on that device is not a minor foothold. As GBHackers notes, it gives attackers a high-privilege position at the network edge for persistence, lateral movement toward systems holding ePHI, ransomware or wiper deployment, and data theft.

Consider a 25-bed Critical Access Hospital with one IT generalist, a single Check Point gateway, and a Mobile Access portal turned on so physicians can reach the EHR from home. That portal is exactly the exposure attackers used here. If the gateway is on R81.20 and was last patched in the summer, it was open to both halves of this chain. The work for that hospital this week is not complicated, but it is urgent: patch, check the logs since October 30, and write down what was done.

The HIPAA angle

A compromised gateway is a security incident to work through, not just a vulnerability to close. Under 45 CFR 164.308(a)(6)(ii), the Response and reporting implementation specification (Required) means identifying and responding to suspected or known security incidents, mitigating harmful effects to the extent practicable, and documenting incidents and their outcomes. Reviewing gateway and portal logs for the IOCs above is also the kind of activity covered by the audit controls standard at 45 CFR 164.312(b) and the Information system activity review specification (Required) at 45 CFR 164.308(a)(1)(ii)(D). The access control standard at 45 CFR 164.312(a)(1) is the broader requirement an unauthorized root shell undermines.

If you find evidence of compromise and the attacker could reach systems containing ePHI, the breach analysis under 45 CFR 164.402 applies: unauthorized access is presumed to be a breach unless a documented risk assessment shows a low probability that the information was compromised. If notification is required, 45 CFR 164.404(b) sets the outer limit at 60 calendar days after discovery. Clean results should be documented too. A record showing the patch date, the mitigation used if any, and the log review performed is worth having if anyone asks later.

What to do, in order

Inventory every Check Point Force Firewall, Management and Log Server, Multi-Domain server, and Maestro Orchestrator. Record the Gaia version and Jumbo take, and identify any internet-facing Mobile Access portals.
Install the November Jumbo Hotfix Accumulator at or above the fixed take for your version, starting with internet-facing gateways and including management servers.
If patching has to wait, apply the sk1000362 mitigation and plan for the loss of Dynamic CLI until you can patch.
Hunt for the published IOCs from October 30 forward, and earlier if logs allow.
Verify the installed take after patching, watch for follow-on activity, and restrict management access to the appliances where you can.
Document the inventory, patch dates, mitigations, and hunting results for your security incident and compliance records.

What is still unknown

Check Point has not publicly confirmed who is behind the attacks. Some independent commentary has suggested Chinese-nexus tooling, but that is unverified. It is also unclear how many organizations beyond the roughly two dozen Check Point observed were affected, whether a public exploit is circulating, and whether CISA will add CVE-2026-123039 to its Known Exploited Vulnerabilities catalog. None of those open questions change the immediate work: patch, hunt, and document.

This article is for informational purposes only and does not constitute legal or compliance advice. Covered entities and business associates should consult qualified legal counsel or compliance professionals before making decisions pertaining to HIPAA or IT infrastructure.