Check Point Gaia Flaw CVE-2026-123039 Exploited to Take Over Gateways and Wipe ESXi Hosts

Check Point has released hotfixes for a Gaia OS flaw, CVE-2026-123039, that attackers have used since late October to take root control of Check Point Security Gateways, and in some cases to go on and wipe VMware ESXi hosts. Check Point says it observed the flaw exploited against “a couple of dozen customers”. The US Cybersecurity and Infrastructure Security Agency (CISA) added it to its Known Exploited Vulnerabilities catalogue on Friday 13 November and gave US federal agencies until Monday 16 November to act, one of the shortest deadlines it sets.

If you run Check Point gateways or management servers, our advice is to treat this as a weekend job, starting with any gateway that has the Mobile Access portal open to the internet.

#The flaw in one paragraph

According to Check Point’s description in the NVD record, the Gaia OS DynamicCLI daemon runs as root and listens on a local socket that any process can write to, without checking who is connecting. Anyone who already has a foothold on the device can send it a command and have it run as root. On its own that needs local access, which is why it is rated 7.8 (High) rather than critical. The danger is what attackers have paired it with.

#How the attacks worked

Check Point Research published its findings on Thursday 12 November. In the intrusions it investigated:

1. Attackers got in through the gateway’s Mobile Access portal, using the PHP2Shell flaws in PHP (CVE-2026-109618 and CVE-2026-109619). PHP patched those on 21 October, BleepingComputer reports, and CISA added them to its catalogue on 26 October.
2. They used CVE-2026-123039 to go from the portal’s service account to root.
3. They planted PHP webshells and a backdoor Check Point calls TSGA, with a networking component called TSProxy.
4. In the first wave, which began on 30 October and targeted Israeli organisations, they moved from the gateway to VMware ESXi hosts over SSH and ran a data wiper, leaving a politically themed note.
5. A second wave on 2 November reached organisations in several countries and sectors. Check Point saw no destructive activity in that wave.

On who is behind it, Check Point says the malware shares code with a framework that ESET has linked to a China-nexus group, but that the evidence “does not allow us to assess with high confidence the true nature of this operation”. We would not attribute it either.

#Are you affected?

CISA’s entry lists Check Point Firewall, Multi-Domain Security Management Server, Scalable Platforms, Security Gateway and Security Management Server. Check Point’s version data in the NVD record lists Quantum Security Gateway and Quantum Security Management at these levels or below as affected:

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

Check Point’s advisory for this flaw is sk1000362 on its support site; check it for the exact fixed takes for your version before you plan the change.

#What to do this weekend

1. Install the November Jumbo Hotfix on every Management Server and Security Gateway, as Check Point recommends, starting with gateways whose Mobile Access portal faces the internet. BleepingComputer reports that it fixes both PHP2Shell and the DynamicCLI flaw.
2. If you cannot patch straight away, Check Point’s temporary mitigation, as reported by BleepingComputer, is to stop the dynamic_server process and stop it restarting. Read the advisory before you do this, and test it on one gateway first.
3. Look for signs you were already hit. Check Point’s indicators, as reported by BleepingComputer, include PHP session files containing upload_progress_pwn, unexpected CPconfigdaemon processes or binaries, and unexplained gaps in firewall logs. Any SSH from a gateway to an internal ESXi host that you did not expect is, BleepingComputer reports, a clear sign of breach.
4. If you find any of those, treat the gateway as compromised. Patching does not remove a webshell or backdoor that is already there. Isolate it, involve Check Point support or your incident responder, and check every ESXi host it could reach.
5. Close the portal if you do not use it. The whole chain starts at the Mobile Access portal. If yours is enabled but unused, turning it off removes the way in.

#Our view

We think this is more serious than its 7.8 score suggests. A local privilege escalation is usually a second-tier problem, but on a firewall it is the step that turns a web bug into full control of the device that guards the network. The attackers then used that device as a launch point to wipe virtualisation hosts, which is about as damaging as an intrusion gets.

It is also part of a pattern. BleepingComputer notes that in September Check Point warned of two other remote code execution flaws exploited as zero-days, and that CISA has added five Check Point flaws to its catalogue in the last two years. Edge devices (firewallsThe KBY LexiconFirewallsA firewall enforces a network trust boundary by filtering traffic against policy; this entry defines the term, its mechanisms, architecture and common misuse. Read Full Context , VPN gateways, remote access portals) have been the favourite way in for serious attackers for some time, across every vendor. Our advice is the same for all of them: keep the management and portal interfaces off the internet unless you need them, patch them first, and log what they do somewhere the attacker cannot reach.

CISA’s three-day deadline applies to US federal agencies, not to UK organisations, but it is a good guide to how urgent CISA thinks this is.