Check Point CVE-2026-123039 Explained: Exploited Gaia Zero-Day, PHP2Shell Chain and the Jumbo Hotfix to Install
Image: Check Point logo — Wikimedia Commons, public domain. The vulnerability affects Check Point Security Gateways running Gaia OS.
TL;DR: Check Point CVE-2026-123039 explained: Check Point disclosed on 12 November 2026 that attackers chained the PHP2Shell flaws in internet-facing Mobile Access portals with a new Gaia OS privilege-escalation flaw, CVE-2026-123039, to take over unpatched Security Gateways. With root access they planted the TSGA backdoor and, in some attacks, wiped VMware ESXi hosts. The fix is the November Jumbo Hotfix — R81.20 Take 174, R82 Take 132, R82.10 Take 52 or R82.20 Take 14 — and patching alone is not enough if a gateway is already compromised.
Key Highlights
- The flaw: CVE-2026-123039 (CVSS 7.8) is a local privilege-escalation bug in Gaia OS DynamicCLI — a root daemon listened on a world-writable socket with no authentication.
- The chain: attackers entered through PHP2Shell (CVE-2026-109618 and CVE-2026-109619) in the Mobile Access portal, then used CVE-2026-123039 to go from the portal service account to root.
- The damage: TSGA backdoor and TSProxy persistence on gateways; in the 30 October wave, attackers pivoted to VMware ESXi hosts and ran the destroy_v6 wiper.
- The scale: Check Point confirmed active exploitation against "a couple of dozen customers". A second wave on 2 November hit organisations in several countries, with no destruction observed.
- The fix: install the November Jumbo Hotfix now; if you cannot patch immediately, stop the dynamic_server process as a temporary mitigation.
Check Point CVE-2026-123039 explained: how the attack chain works
Check Point Research disclosed the campaign on 12 November 2026, and the company's security advisory followed the same day. The activity ran in two waves. On 30 October, traffic from a single IP address began hitting internet-facing Check Point Mobile Access portals belonging to Israeli organisations, about a week after the gateway fix had become available. Several of those intrusions ended with a wiper running on internal virtualisation infrastructure. On 2 November, a wider wave spread across regions and industries, revisiting some of the earlier targets along with unrelated organisations worldwide — and it deployed no destructive payloads. Check Point says exploitation was observed as active until 4 November.
The entry point was not a flaw in Check Point's firewall inspection engine. It was the PHP runtime behind the Mobile Access portal. PHP2Shell covers two remote code execution vulnerabilities in the PHP engine, CVE-2026-109618 and CVE-2026-109619, both rated CVSS 9.2. Upstream PHP maintainers patched both on 21 October, and Check Point says gateway fixes were available on 23 October — a week before the attacks began. The gateways that were hit were the ones that had not been patched.
Once inside, the attackers left plenty of forensic traces: PHP session files carrying the marker upload_progress_pwn in the portal's temporary directory, and hundreds of segmentation faults in the portal's Apache and PHP worker processes as the exploit probed for a reliable heap layout. But code execution at this stage ran only as the unprivileged portal service account. To take full control of the gateway, the attackers needed a second vulnerability inside Gaia OS — and they had one.
The flaw: a world-writable socket running as root
CVE-2026-123039 sits in the DynamicCLI daemon, dynamic_server, which runs as root and handles command-line configuration requests across Check Point appliances. It is rated CVSS 7.8 and classified as CWE-306, Missing Authentication for Critical Function.
In affected releases, dynamic_server bound to a local Unix domain socket at /tmp/dynamic_socket with world-writable permissions (0777). It performed no peer-credential check and no session-token validation. Any local user — or any compromised service account, such as the portal account the attackers already controlled — could write a command to that socket and have it executed as root. Because the socket accepted raw command payloads without routing them through the restricted Clish shell wrapper, the abuse also left distinctive entries in /var/log/dynamicCli.log, which is now one of the key hunting signals.
The flaw affects Gaia releases R81, R81.10, R81.20, R82, R82.10 and R82.20, across Quantum Security Gateways, Force Firewalls, Security Management and Log Servers, Multi-Domain Security Management environments and Maestro Orchestrators. Spark Firewalls and Smart-1 Cloud are not affected. It is important to be precise about the severity: at 7.8, this is not the entry point. It is the bridge between a web-shell foothold and full root control — and it only works once an attacker already has local code execution on the appliance.
TSGA, TSProxy and the ESXi wiper
With root on the gateway, the attackers built two layers of persistence designed to survive service restarts, configuration backups and routine admin audits. The first was a set of PHP web shells written into the Mobile Access portal's login template directory, gated behind a hardcoded authentication parameter, zz2026. The second was TSGA, a passive Linux backdoor staged to resemble a legitimate Check Point configuration binary at /tmp/CPconfigdaemon, which copied itself into the appliance's boot persistence directory and survived cold reboots.
TSGA shows detailed knowledge of Gaia OS internals. It hooks the backup and snapshot routines so the implant survives configuration rollbacks, it can edit Check Point's proprietary binary firewall log files to scrub records of its own command-and-control sessions, and it harvests gateway configuration files — including VPN pre-shared keys, certificate material, routing tables and the Secure Internal Communication trust parameters used to authenticate with management servers. It carries an embedded shared object, TSProxy, written to /lib/libcpfwcommon.so to blend in with genuine firewall libraries. Injected into running appliance daemons, TSProxy watches network traffic for a magic byte sequence and opens an encrypted SOCKS-style proxy tunnel, while ordinary traffic passes through untouched.
.jpg?width=900 "VMware ESXi hosts targeted by destroy_v6 wiper")
Illustrative image: server racks in a data centre (Carl Lender, CC BY 2.0, via Wikimedia Commons). The attackers pivoted from compromised gateways to VMware ESXi hosts running virtual machines.
From the gateway, the operators mapped the subnets behind the firewall with an open-source scanner, then opened SSH sessions to internal VMware ESXi hosts using the vpxuser account — the privileged local account vCenter Server creates to administer each hypervisor. On the targeted hosts they staged a Linux wiper at /tmp/des, known as destroy_v6. Run without its fast flag, it walks a directory tree recursively and overwrites virtual machine disk images, snapshots and configuration files with null bytes before deleting them, defeating block-level forensic recovery. In every directory it processed, it dropped a text file named DREAM_ANNEXATION.txt containing a timestamp, political messaging about the Israeli-Palestinian conflict, a rejection of ransom negotiations and a direct mention of the Israeli cybersecurity firm Dream Security — which had recently published research linking China-nexus actors to PHP2Shell exploitation against Palo Alto Networks appliances.
That detail is why attribution is genuinely unresolved. Code analysis ties TSGA and TSProxy to PhiliKit, a modular Linux implant framework ESET documented in June 2026 during investigations into Ivanti VPN compromises attributed to the China-nexus cluster Armory Castle (formerly tracked as UNC5221). The two share cryptographic framing, a command loop derived from Tiny SHell, the socket path /tmp/.p_sock and a listener on TCP port 11072. Scanning telemetry also clustered inside China business hours. Against that, a noisy wiper paired with political messaging sits poorly with established Chinese state espionage practice, which overwhelmingly favours quiet, long-term collection over destruction. Check Point's own assessment is that the evidence cannot separate a single China-nexus group running an atypical destructive operation, an initial-access broker selling the foothold to a politically motivated actor, or a deliberate false flag. This post does not pick one.
Affected versions and the fix
The fix is the November 2026 Jumbo Hotfix. Check Point lists a fixed take for each affected release train. The table below is the authoritative list from the advisory:
| Gaia release | Fixed Jumbo Hotfix take | Status |
|---|---|---|
| R81.20 | Take 174 | Fixed |
| R82 | Take 132 | Fixed |
| R82.10 | Take 52 | Fixed |
| R82.20 | Take 14 | Fixed |
| R81 / R81.10 | No fixed take listed | Upgrade and use the mitigation below |
If you cannot patch immediately, Check Point's temporary mitigation is to stop the dynamic_server process and prevent it from restarting. That closes the privilege-escalation path but disables DynamicCLI functionality until you patch. Patching the PHP2Shell side matters just as much: closing only one link in the chain leaves the other open.
Patching a gateway that is already compromised will not remove the backdoor. TSGA embeds itself in boot persistence directories and in Gaia backup and snapshot archives, so a patched-but-compromised gateway stays compromised. Security teams should hunt for the published indicators before — or immediately after — patching: PHP session files containing upload_progress_pwn, unexpected zz*.tpl files in the portal template directories, commands in /var/log/dynamicCli.log that bypass the Clish wrapper, a socket at /tmp/dynamic_socket still showing 0777 permissions, CPconfigdaemon or slot_CPconfigdaemon in startup directories, listeners on TCP port 11072, and DREAM_ANNEXATION.txt on ESXi datastores. If any of these turn up, rebuild the gateway rather than cleaning it in place. At the time this article was first published on 13 November 2026, CVE-2026-123039 had not yet been added to CISA's Known Exploited Vulnerabilities catalogue — see the update at the top of this post: CISA added it to the catalogue later on 13 November 2026, with a patch deadline of 16 November 2026. — but Check Point's own confirmation of exploitation against a couple of dozen customers is reason enough to act.
Why it matters for Indian readers
Check Point gateways are widely deployed in Indian enterprises, banks and government networks, and the entry point here is an internet-facing Mobile Access portal — exactly the kind of service that is easy to leave exposed and easy to forget. If your organisation runs a Check Point Security Gateway, the question is not whether the flaw is theoretical. Check Point has confirmed real-world exploitation, the fix has been available since 23 October, and the campaign specifically targeted gateways that had not applied it.
For Indian security teams, two things deserve attention beyond the patch itself. First, the wiper angle: the attack did not stop at the perimeter. A compromised gateway became a launchpad into the virtualisation layer, where the damage — overwritten virtual machine disks — is far harder to recover from than a breached firewall. Backups that live on the same infrastructure as the ESXi hosts are worth checking. Second, the attribution fog: the tooling points one way and the final objective points another, which means defenders should not wait for a clean attribution story before hunting. The indicators of compromise are published and specific, and they work regardless of who was behind the keyboard.
This is also the third Check Point zero-day story in as many months — in September the company warned of two other exploited flaws in its Security Management Server and Security Gateway. The pattern is now clear: perimeter appliances are a prime target, and the window between a fix being available and attackers exploiting the unpatched remainder is measured in days. That is the lesson to carry into the next advisory, whichever vendor it names.
Should you care? ✅ / ⏳
✅ Patch now if you run Check Point gateways — especially any gateway with an internet-facing Mobile Access portal. Install the November Jumbo Hotfix for your release train, then hunt the published indicators; a patch does not clean a compromised box. ⏳ Everyone else: no action needed, but the pattern matters — keep an eye on the next perimeter-appliance advisory, because the exploitation window is now measured in days, not weeks.
FAQs
What is CVE-2026-123039?
CVE-2026-123039 is a local privilege-escalation vulnerability in Check Point's Gaia OS, rated CVSS 7.8. The DynamicCLI daemon, which runs as root, listened on a world-writable local socket (/tmp/dynamic_socket) without authenticating connecting processes, so any local user could send commands to be executed as root. Attackers chained it with the PHP2Shell flaws to take over unpatched Check Point Security Gateways in October and November 2026.
Which Check Point versions are affected by CVE-2026-123039?
Gaia releases R81, R81.10, R81.20, R82, R82.10 and R82.20 are affected, across Quantum Security Gateways, Force Firewalls, Security Management and Log Servers, Multi-Domain environments and Maestro Orchestrators. Fixed Jumbo Hotfix takes are R81.20 Take 174, R82 Take 132, R82.10 Take 52 and R82.20 Take 14. Spark Firewalls and Smart-1 Cloud are not affected, and no fixed take has been listed for R81 or R81.10.
How do I fix CVE-2026-123039?
Install the November 2026 Jumbo Hotfix for your Gaia release train as soon as operationally possible, and patch the PHP2Shell flaws in the Mobile Access portal at the same time. If you cannot patch immediately, stop the dynamic_server process and prevent it from restarting as a temporary mitigation — this disables DynamicCLI until you patch. Then hunt for the published indicators of compromise, and rebuild any gateway that shows signs of compromise rather than cleaning it in place.
Is CVE-2026-123039 being exploited in the wild?
Yes. Check Point confirmed active exploitation against "a couple of dozen customers" in its 12 November 2026 advisory, with activity observed from 30 October to 4 November 2026. The first wave targeted Israeli organisations and included destructive wiper attacks on VMware ESXi hosts; a second, wider wave on 2 November reached organisations in several countries with no destruction observed.
Takeaway
CVE-2026-123039 is a reminder that the most dangerous flaw in a chain is not always the highest-scored one. A 7.8 local privilege escalation turned a web-shell foothold into full root control of a security gateway, and from there into wiped virtual machines. The fix has been available since late October — check your gateway's Jumbo Hotfix take today, and if you run Check Point gear, read our earlier explainers on the MongoDB CVE-2026-118383 patch and the Citrix NetScaler November 2026 flaws to see how fast this month's patching window is closing. For the backdoor lineage, see also our Ivanti Connect Secure zero-day chain post — the same implant family showed up there first.
Sources
Check Point Blog — Security Advisory: Active Exploitation of PHP2Shell and Local Privilege Escalation
BleepingComputer — Check Point warns of zero-day flaw exploited for root access
Security Affairs — Unpatched Check Point Gateways Are Being Wiped exploiting PHP2Shell
GBHackers — Hackers Exploit Check Point PHP2Shell Flaws to Gain Root Access and Deploy Wiper Malware
The CyberSec Guru — Check Point CVE-2026-123039: PHP2Shell, TSGA and ESXi Wipers
Comments
Post a Comment