Attackers rooted Check Point gateways through the Mobile Access portal and wiped servers behind them. Install the new hotfix.

Check Point says attackers used the PHP2Shell flaws in the Mobile Access portal, then a new root bug in Gaia's DynamicCLI service, CVE-2026-123039, to backdoor Security Gateways and wipe a VMware ESXi host. It has emergency hotfixes for R81 through R82.20 and saw the root exploit used against a couple of dozen customers.

If you run a Check Point Security Gateway with the Mobile Access portal turned on, install Check Point’s emergency hotfix for CVE-2026-123039 today and confirm the earlier PHP2Shell fix is in place. If you can’t patch yet, Check Point’s advisory says to stop the dynamic_server process and keep it from restarting. If your portal was reachable from the internet and unpatched at any point since late October, treat the gateway as possibly compromised and look for the signs listed below.

What Check Point found

Check Point Research published the attack chain on November 12. Attackers first broke in through the Mobile Access portal on unpatched gateways, using the PHP2Shell flaws, CVE-2026-109618 and CVE-2026-109619. Check Point says that wave started about one week after a fix for PHP2Shell became available.

From the portal’s service account, the attackers then got root through a second flaw that had not been reported before. That flaw, CVE-2026-123039, sits in the DynamicCLI service of Check Point’s Gaia OS. According to BleepingComputer, the service runs as root and listens on a local socket that any process can write to, without checking who is connecting. Check Point’s advisory says it “observed an active exploit of this vulnerability against a couple of dozen customers.”

• The root bug: CVE-2026-123039, a missing authorization check, rated 7.8 on the CVSS scale according to The Hacker News. It needs code already running on the appliance, which is what the PHP2Shell break-in provided.
• Affected versions: R82.20, R82.10, R82, R81.20, R81.10 and R81, according to The Hacker News. BleepingComputer lists Security Gateway, Security Management Server, Multi-Domain Security Management, Scalable Platforms and Firewall products.
• Fix: emergency hotfixes from Check Point. The research post and the news reports don’t list hotfix numbers, so take them from the advisory for your version.

What the attackers did with root

The first wave, starting October 30, hit Israeli organizations. A second wave on November 2 reached organizations in several countries with no clear sector focus, which Check Point reads as opportunistic. On compromised gateways the attackers:

• planted PHP web shells in the portal’s templates directory;
• installed a backdoor Check Point calls TSGA, running as slot_CPconfigdaemon, with a component called TSProxy that hides attacker connections inside normal gateway traffic;
• scanned the internal network from the gateway;
• logged in over SSH to a VMware ESXi host with the vpxuser account, then ran a wiper called destroy_v6 that zeroes and deletes files, leaving a note named DREAM_ANNEXATION.txt.

The destructive step showed up in the first wave. Check Point says it found no destruction in the second.

Who is behind it is unclear

Check Point ties the TSGA backdoor to a toolkit that ESET documented in June and linked to a China-nexus espionage group tracked as UNC5221. The wiper note, though, refers to the Israeli-Palestinian conflict. Check Point says the evidence “does not allow us to assess with high confidence the true nature of this operation.” It lists three possibilities: one actor ran everything, the group only sold access, or the destruction was a false flag or smoke screen.

What to do

• Patch both layers. Install the PHP2Shell fix and the CVE-2026-123039 hotfix. The first closes the way in; the second closes the way to root.
• Use the stopgap if you must wait. Stop dynamic_server and keep it from restarting until the hotfix is on, per Check Point’s advisory.
• Check whether Mobile Access needs to face the internet. If few people use the portal, turn it off or restrict it to known IP ranges.
• Hunt on the gateway. Look for unexpected PHP files in the portal templates directory and a process named slot_CPconfigdaemon.
• Hunt behind it. Review ESXi logs for SSH logins by vpxuser that came from the gateway, and block SSH from the gateway to your hypervisors if nothing needs it.
• Assume credentials leaked if you find anything. The backdoor can steal gateway configuration, so rotate VPN, admin and service account secrets after you rebuild.

Your firewall is now a front door

This is our analysis. The VPN and firewall stories we covered in the past month share a shape: an internet-facing login page on a security appliance becomes the way in. Ivanti Connect Secure gave attackers root on gateways that were fully patched at the time, and SonicWall had an MFA bypass on its SSL VPN. The lesson for a small company with one firewall and no security team is about exposure. Every portal you turn on is one more login page open to the internet, and it runs on the device that is supposed to protect you. Keep a short list of which portals are on, who uses them and when each was last patched. If a portal sat unpatched for a week after a fix shipped, as the first victims’ portals did, the hotfix alone does not tell you whether someone already got in.