Check Point CVE-2026-123039: PHP2Shell-to-Root Chain Deploys TSGA Backdoor, Wipes ESXi Hosts

Check Point Software disclosed CVE-2026-123039 in November 2026, a zero-day vulnerability chain in its Gaia operating system that lets attackers escalate a web-shell foothold on Security Gateways into full root access. Threat actors paired it with a PHP2Shell exploit to install a backdoor called TSGA, tamper with firewall logs, and wipe VMware ESXi hosts across Israel and other countries.

Key takeaways

• CVE-2026-123039 is a root-escalation flaw in Check Point's Gaia OS, tracked by CISA as a DynamicCLI root escalation and fixed in R82.20 Take 14.
• Attackers chained a PHP2Shell web-shell exploit with CVE-2026-123039 to go from low-privilege gateway access to root in one move, per Check Point Research.
• Once rooted, the attackers installed a persistent backdoor called TSGA, tampered with firewall logs, and deployed a wiper against VMware ESXi hosts.
• CISA added the flaw to its Known Exploited Vulnerabilities catalog, which requires federal patching on a deadline and is a strong signal for every MSSP running Check Point in production.

What is CVE-2026-123039?

CVE-2026-123039 is a privilege-escalation vulnerability in Gaia, the operating system that runs Check Point Security Gateways, allowing an attacker who already has limited code execution on the device to escalate to root. Check Point patched the flaw after confirming active exploitation, and the fix shipped in R82.20 Take 14.

CISA's Known Exploited Vulnerabilities entry refers to the flaw by its underlying mechanism as a DynamicCLI root escalation, confirming that attackers are actively using it in the wild, not just testing it in a lab. Gateways running unpatched Gaia builds remain exposed until the update is applied.

How does the PHP2Shell-to-root chain work?

PHP2Shell is the exploitation technique Check Point Research documented for abusing the gateway's web management interface to achieve initial code execution. On its own, PHP2Shell gets an attacker a low-privilege shell. Chained with CVE-2026-123039, that shell becomes root.

Check Point Research attributes the campaign to an unknown actor deliberately targeting unpatched Check Point Security Gateways, confirming this is not opportunistic scanning noise but a repeatable attack chain built around the firewall itself.

What is the TSGA backdoor, and why does log tampering matter?

TSGA is the persistent backdoor attackers installed after reaching root on the compromised gateways, letting them maintain command execution independent of the device's patch state. A backdoor at this layer does not just read traffic, it controls the device that every other security tool assumes is trustworthy.

The more consequential move is what CSOonline describes as turning the firewall against the customer: the attackers' toolkit specifically tampers with firewall logs. Any SOC pipeline that ingests those logs and trusts them unconditionally inherits that tampering as fact. From there, the campaign deployed a wiper against VMware ESXi hosts, destroying virtual infrastructure once the backdoor and evasion were in place.

Who is affected, and what should partners do right now?

Organizations in Israel and other countries have already been hit by this exploitation chain, according to reporting on the campaign, and Check Point confirmed wiped Israeli systems tied to the same actor. Any MSSP or MSP managing Check Point gateways for clients should treat this as active, not theoretical.

Immediate priorities:

• Apply the R82.20 Take 14 fix to every managed Check Point gateway without exception.
• Confirm CISA's KEV deadline for any client with federal or regulated obligations.
• Hunt for TSGA backdoor indicators on gateways that were unpatched at any point since the vulnerability became active, not just ones currently unpatched.
• Do not rely solely on the gateway's own logs to confirm it is clean. If the attacker's toolkit tampers with logs, a log review alone cannot prove absence of compromise.
• Verify the integrity of any ESXi hosts reachable from or managed alongside the affected gateways.

Why alert-only monitoring missed this

Alert-only monitoring fails here because it is built on a quiet assumption: that the device generating the logs is telling the truth. This campaign's toolkit was built specifically to defeat that assumption, tampering with firewall logs as a standard step in the chain, not an afterthought. A SIEM that ingests and trusts vendor-supplied logs without an independent view is architecturally blind to an attacker who planned for exactly that SIEM.

This is the gap Vijilan Security built its Global SOC model to close. ThreatRespond™, our managed XDR service, correlates signal across sources rather than trusting any single device's self-reported state, and 24/7 SOC monitoring backed by analysts means containment decisions do not wait for a compromised log source to confess. When a device like a firewall is the attack surface itself, detection has to come from somewhere the attacker does not control, and action has to follow without waiting for that device to agree it has a problem.

For MSSP partners running Check Point gateways on behalf of clients, proactive threat hunting for backdoors like TSGA and incident response services for suspected ESXi compromise matter more than another dashboard. And to be direct about where Vijilan fits in your stack: we never compete with our partners for their clients. Our job is the SOC behind your brand, not a reason to go around you.

What to do next

Patch CVE-2026-123039 first, then verify. Review why Vijilan's model differs from log-trusting monitoring and talk to us about getting independent, out-of-band eyes on your Check Point infrastructure before the next gateway-targeted campaign assumes your SOC will believe whatever the firewall tells it.