Check Point Rushes Hotfixes for a Firewall Zero-Day Used to Take Root. Attackers Chained It With PHP2Shell and Wiped a VMware Host
Check Point has issued emergency hotfixes for CVE-2026-123039, a Gaia OS flaw that attackers used against a couple of dozen customers to turn a foothold from PHP2Shell into root on Security Gateways. In some cases they moved on to a VMware ESXi host and ran a wiper.
Check Point has pushed out emergency hotfixes for a flaw in its Gaia operating system that attackers have been using since late October. The bug lets anyone already running code on a gateway jump to root. Check Point says it has seen the exploit used against about two dozen customers, and some of the intrusions ended with files wiped on a virtualization server sitting behind the firewall.
This briefing draws on BleepingComputer’s report on the Check Point zero-day, along with coverage of Check Point’s attack analysis by The Hacker News and SecurityWeek.
The flaw in one paragraph
The bug is tracked as CVE-2026-123039 and rated 7.8 on the CVSS scale. It sits in DynamicCLI, a root-level Gaia service that accepts privileged command requests. In its advisory, Check Point says the service listens on a local socket that any process can write to and never checks who is connecting. A logged-in local user can therefore send it a command and have that command run as root. On its own, the flaw is not a way in from the internet. It only helps an attacker who already has code running on the appliance, and this campaign got that first step from a different bug.
Which products are in scope
- Versions R81, R81.10, R81.20, R82, R82.10 and R82.20.
- Products named in the reports: Security Gateway and Firewall, Security Management Server, Multi-Domain Security Management (including the Multi-Domain Log Server), and Scalable Platforms.
How the attacks played out
- Wave one, from October 30: Check Point says the activity hit Israeli organizations through vulnerable Mobile Access portals on Security Gateways. It began about a week after fixes were released for PHP2Shell (CVE-2026-109618 and CVE-2026-109619), the PHP flaws used to get in.
- From portal account to root: The attackers used CVE-2026-123039 to escalate from the portal’s service account. SecurityWeek reports that they then placed PHP web shells in the folder the portal uses to build its login pages.
- Staying in: Next came a backdoor Check Point calls TSGA and a companion component, TSProxy. According to Check Point, TSGA is built specifically for these gateways. It provides encrypted remote access, can steal configuration, survives in backups and snapshots, and can tamper with firewall logs. TSProxy hooks into the appliance’s own processes so specially marked attacker traffic is handled quietly while normal traffic carries on.
- Moving inward: The attackers used a scanning tool to map internal systems, then connected over SSH to a VMware ESXi host using the vpxuser service account.
- The destructive step: On the ESXi host they ran a Linux wiper called destroy_v6. It tries to overwrite files with zeros and then deletes them, and the attackers left politically themed notes behind.
- Wave two, from November 2: A wider round hit Security Gateways at organizations in several countries, including some already targeted in wave one. Check Point saw no clear sector preference and no destructive activity in this second wave.
Who is behind it is still unclear
TSGA and TSProxy belong to a toolkit that ESET has linked to a China-nexus espionage group. The infrastructure used and the hours the attackers kept also point in that direction. Even so, Check Point says the evidence is not strong enough to name an actor with high confidence. Wiping data and focusing on Israel do not fit known Chinese operations, the company notes. It says the actor may have run the whole campaign, sold the access to someone else, staged a false flag, or used the destruction as a smoke screen.
If you can’t install the hotfix today
- Check Point’s stopgap is to stop the dynamic_server process and keep it from restarting until the hotfix is in place.
- The company has published indicators of compromise. It also suggests reviewing logs for commands typical of exploitation, for use of the system() call (rare in legitimate traffic), and for commands that skipped the default Clish wrapper. That last pattern suggests something ran as root through the socket and needs a closer look.
- Patching the PHP2Shell flaws and the new bug blocks fresh attempts. It does not remove web shells or backdoors planted before the fix.
What this means for your company
A firewall or VPN gateway is the device you trust to keep attackers out, so an intrusion there is especially dangerous. This campaign also shows how quickly a gateway foothold can lead to the servers behind it. If your business runs any internet-facing gateway or remote-access portal, whoever the vendor is:
- Know exactly which software versions you run and who is responsible for applying emergency fixes, including outside business hours.
- Where a portal gets a critical fix, assume it may have been probed before you patched. Check for unexpected files and accounts, not just the version number.
- Keep management access to hypervisors such as ESXi off networks a compromised gateway can reach, and treat service accounts like vpxuser as high-value credentials.
- Keep at least one recent backup offline or immutable so a wiper on a virtualization host cannot take your recovery copies down with it.
- Send gateway logs to a separate system, since the backdoor described here can tamper with logs stored on the device.
If you are unsure whether your firewall or VPN portal has been fully checked since October, we can help review it. Reach out to Layer 7 Data Solutions to discuss how we’ve helped companies similar to yours.
About The Author
