HIGH: Check Point Gaia Flaw CVE-2026-123039 Exploited to Root Firewalls

There is a special kind of dread that comes from finding out the box sitting at the edge of your network, the one whose entire job is keeping attackers out, has been quietly working for someone else. Check Point customers are getting a fresh dose of that feeling this week. The company has confirmed that attackers chained the PHP2Shell remote code execution bugs with a previously unreported Gaia OS privilege escalation to take full root control of Security Gateways, plant a purpose-built backdoor called TSGA, and in some cases pivot into VMware ESXi hosts and wipe them.

The privilege escalation is tracked as CVE-2026-123039 and carries a CVSS score of 7.8. That number looks almost polite on paper. In practice it is the piece that turns a foothold in a web portal service account into total ownership of a firewall. CISA added it to the Known Exploited Vulnerabilities catalog on November 13 and gave federal agencies until November 16 to fix it. That is a three day window, which tells you exactly how seriously the agency is taking this one. Check Point itself says it has seen the flaw exploited against "a couple of dozen customers."

How the chain works

The front door here is PHP2Shell, the pair of PHP engine flaws tracked as CVE-2026-109618 and CVE-2026-109619 that we covered when they dropped in late October. Those bugs give an unauthenticated attacker code execution in any PHP runtime that answers a request, and it turns out the Mobile Access portal on Check Point Security Gateways is one of those runtimes. According to Check Point, activity from the IP address 130.94.19[.]204 began probing vulnerable Mobile Access portals roughly a week after fixes for the PHP issues became available, with the campaign proper kicking off on October 30. A week. That is how long the patch window lasts now, and anyone still running quarterly maintenance cycles on perimeter gear should sit with that for a minute.

Landing code execution through the portal only gets an attacker into a low privilege service account, which is where CVE-2026-123039 comes in. The bug lives in the Gaia OS DynamicCLI daemon. CISA's description explains that the daemon runs as root and listens on a world writable local socket without authenticating whoever connects to it. Any authenticated local user can send a single request to that socket and have the command executed as root. There is no memory corruption trick here and no race to win. It is a root shell sitting on a socket with the door propped open, classified under CWE-732 and CWE-862 for incorrect permission assignment and missing authorization. Check Point is careful to note the attacker needs local code execution first, which is technically true and also exactly what PHP2Shell provides.

The affected Gaia releases are R81, R81.10, R81.20, R82, R82.10 and R82.20, which covers basically every supported deployment out there. The product list is broad as well. Check Point and CISA name Security Gateways and Firewalls, Security Management Servers, Management and Log Servers, Multi-Domain Security Management and Multi-Domain Log Servers, Scalable Platforms, and the Maestro Orchestrator. If it runs Gaia, assume it is in scope until the advisory tells you otherwise.

What the attackers did once they had root

With root on the gateway, the operators dropped PHP web shells for command execution and file upload, then installed TSGA under the innocuous looking name slot_CPconfigdaemon. Check Point describes TSGA as a standalone passive backdoor built specifically for its own appliances, which is a sobering detail on its own. Someone invested real engineering time in understanding Gaia internals. The implant offers encrypted remote access, steals gateway configuration, persists through backups and snapshots, injects into running processes, and tampers with the binary firewall logs. That last capability deserves emphasis. The logs you would normally pull during an investigation may have been edited by the very people you are investigating.

TSGA ships alongside a companion component called TSProxy. Its injection code loads a library into selected appliance processes and hooks their networking functions, so specially marked attacker connections get handled by the implant while legitimate traffic flows through normally. Check Point summarized the design as one that "combines a persistent standalone backdoor with concealed access through existing appliance services." In plain English, the attackers can talk to the gateway through ports that are supposed to be open anyway, and nothing looks out of place.

From there the operators ran the gogo scanner on the gateway itself to map internal assets and services. Using your victim's firewall as a reconnaissance platform is efficient and frankly a little insulting. They then moved laterally over SSH to VMware ESXi hosts, authenticating with the vpxuser service account that vCenter uses to manage hosts. On some of those hosts they staged destroy_v6, a Linux ELF wiper that walks directories recursively, tries to overwrite every file with zeros, and then deletes it regardless of extension. It leaves a note called DREAM_ANNEXATION.txt in each directory it processes, with politically themed content referencing the Israeli Palestinian conflict.

Who is behind it, and why nobody is sure

The first wave on October 30 focused on Israeli organizations, and several of those victims are the ones that got wiped. A second, broader wave on November 2 revisited some Israeli targets but also hit organizations across multiple countries and sectors with no obvious pattern, which looks a lot more opportunistic.

Attribution is where things get murky. Check Point assesses TSGA and TSProxy as Check Point specific modules of PhiliKit, a toolkit ESET first documented in June 2026 and linked to the China nexus group Armory Castle, formerly tracked as UNC5221. The infrastructure ran on LightNode VPS servers, and scanning clustered in overnight UTC hours that line up neatly with a Chinese working day. On the other hand, wiper malware and an Israel focused political message are not the usual calling cards of a Chinese espionage crew, which typically prefers to stay quiet and keep access for years. Check Point openly says the evidence "does not allow us to assess with high confidence the true nature of this operation," and lists a single actor, an initial access broker selling footholds, a false flag, or destruction as a smokescreen as all plausible. That honesty is refreshing. It also means defenders should not assume they are safe because they do not fit a particular victim profile.

What to do right now

If you manage Check Point gear, this is a "prioritize it today" situation. Start with the Check Point advisory for CVE-2026-123039, published as sk1000362, and apply the fix for your Gaia version on every gateway, management server and Maestro orchestrator in the estate. Confirm the PHP2Shell fixes for the Mobile Access blade are in place as well, because closing the escalation without closing the front door only buys you time. If Mobile Access is enabled but nobody actually uses it, turn it off. If it is needed, restrict who can reach the portal and stop exposing it to the entire internet.

Patching does not undo a compromise, and CISA's KEV entry explicitly flags this vulnerability for forensic triage. Any gateway with an internet facing Mobile Access portal that was unpatched at any point after late October should be treated as potentially compromised. Look for a process or file named slot_CPconfigdaemon, unexpected PHP files under the portal's web directories, the gogo scanner binary, and any connections to or from 130.94.19[.]204. Because TSGA can rewrite firewall logs, do not trust the gateway's own logs as your only source of truth. Pull flow data from upstream routers, your SIEM and your EDR telemetry, and compare. Check Point's research post includes the fuller indicator set, and it is worth loading into your detection stack.

On the virtualization side, review ESXi authentication logs for SSH sessions using vpxuser, particularly from gateway or management IP addresses. That account has no business opening interactive SSH sessions, so any hit is a strong signal. Disable SSH on ESXi hosts where it is not actively required, keep the management network segmented so the firewall cannot reach hypervisor management interfaces directly, and search for DREAM_ANNEXATION.txt or the destroy_v6 binary. Finally, verify that your backups are offline or immutable and actually restorable. A wiper that lands on the hypervisor layer takes out everything that runs on top of it, and the only real answer to that is a recovery copy the attacker could not reach.

If a gateway does turn out to be compromised, rebuilding it from known good media and rotating every credential it stored, from VPN secrets to administrator passwords and the vCenter service account, is the sane path. Trying to clean an implant that persists through snapshots and backups is a great way to discover that it is still there three weeks later.

The broader lesson is one we keep relearning. Perimeter appliances are some of the most attractive targets on the internet right now, they rarely run EDR, and their logs can be bent by whoever holds root. Treat them like the high value servers they are, patch them with the same urgency as a domain controller, and keep an independent record of what is going on around them.

If an IT provider manages your systems

If your firewall is a Check Point appliance, you should know that attackers are actively using CVE-2026-123039 to take full control of these devices and reach the servers behind them. A patch alone does not show whether you were already hit, so raise this with whoever runs your IT this week.

• Have you applied Check Point advisory sk1000362 and the PHP2Shell fixes to every Gaia device we own, and on what date?
• Is the Mobile Access portal turned on, and who can reach it from the internet?
• Have you checked our gateways and ESXi hosts for slot_CPconfigdaemon or vpxuser SSH logins, using logs from outside the firewall?

A good answer gives dates and confirms the checks were done. It also confirms your backups are offline or immutable. If they hesitate, or a gateway was exposed and unpatched at any point after late October, bring in incident response before you assume it is clean.

If you are an IT provider yourself, see how we partner with MSPs.