Skip to main content

Neotech Cloud Solutions

Home/Cybersecurity/Check Point vulnerability: firewalls hacked all the way to wiped VMware servers
Câbles réseau branchés dans un commutateur d'une salle de serveurs

Check Point vulnerability: firewalls hacked all the way to wiped VMware servers

Your firewall is supposed to be the armoured door of your network. This week, Check Point, one of the major firewall makers, confirmed that attackers exploited a previously unknown Check Point vulnerability to take full control of unpatched gateways. In a few cases, they then went on to wipe VMware ESXi servers behind the firewall.

Check Point says fixes were available a week before the attacks began, and that about two dozen unpatched systems were compromised, in a single region. If your company or your IT provider uses a Check Point firewall, here’s what happened and what to check.

One week between the fix and the attack

Timeline of the case (2026 dates)

Oct. 21

PHP releases emergency fixes for PHP2Shell

Oct. 23

Check Point PHP2Shell fix available

Oct. 30

First wave of attacks, against Israeli organizations

Nov. 2

Second wave, several countries and sectors

Nov. 4

Last activity observed by Check Point

Nov. 12-13

Check Point advisory, then added to CISA’s catalog

Sources: Check Point, BleepingComputer, The Hacker News. According to Check Point, gateways that had received the PHP2Shell fix before October 30 had closed the entry point of this attack chain.

The attack chain, link by link

The attackers chained two flaws. The first, PHP2Shell (CVE-2026-109618 and CVE-2026-109619), affects the PHP language used by the gateways’ Mobile Access portal, the page employees use to connect remotely. We covered it in our article on the critical PHP vulnerability. The second, CVE-2026-123039, was a zero-day in Check Point’s own Gaia operating system.

Link 1

CVE-2026-109618/109619

Entry through the portal

PHP2Shell lets an attacker run code without a password on the internet-facing Mobile Access portal.

🔗

Link 2

CVE-2026-123039

Full takeover

A missing authorization check in the DynamicCLI service grants root rights on the gateway.

🔗

Link 3

TSGA + TSProxy

Hidden backdoor

The attacker installs web shells and a backdoor disguised as a Check Point component (CPconfigdaemon).

🔗

Link 4

gogo + SSH

Network mapping

From the firewall, the attacker maps the internal network and connects over SSH to VMware ESXi servers.

🔗

Link 5

destroy_v6

Wiping

In some cases, a destructive tool deletes files and leaves a political note, with no ransom demand.

Check Point does not attribute the attack with confidence. The tools resemble a kit already associated with a China-linked group, but the wiping and the political message don’t match that group’s habits. The vendor lists several scenarios, including an initial access broker or a false-flag operation.

Check Point vulnerability: is your firewall affected?

The privilege escalation flaw affects Gaia versions including R81.20, R82, R82.10 and R82.20. PHP2Shell also affects gateways with the Mobile Access portal enabled, including some versions of the Spark firewalls designed for small businesses, according to Check Point’s table. Fill in this sheet with the person who manages your firewall:

FIREWALL SHEET — to fill in
Brand and model
____________
Check Point Quantum, Spark, or another brand? If it’s not Check Point, skip to the last section.
Gaia version
R8_.__
Affected by CVE-2026-123039: including R81.20, R82, R82.10 and R82.20.
Mobile Access portal
enabled / disabled
This is the entry point that was used. If it’s reachable from the internet, the gateway was a priority.
Jumbo Hotfix installed
Take ___
Fixed starting with: R81.20 Take 174, R82 Take 132, R82.10 Take 52, R82.20 Take 14.
Installation date
__ / __ / 2026
Before October 30: very good news. After: also run the checks below.
VMware servers behind it
yes / no
Can the firewall open an SSH session to these servers? Normally, it shouldn’t need to.

If you can’t install the fix right away, Check Point describes a temporary mitigation in advisory sk1000362: stopping the dynamic_server service, at the cost of some administration commands.

Patching isn’t enough: the traces to look for

A fix closes the door, but it doesn’t remove a backdoor that’s already installed. Check Point asks customers to check gateways that were exposed. Here are the published indicators, turned into concrete tasks for your IT provider:

🗂️ Suspicious session files

A sign that PHP2Shell was exploited.

🔎 Look for: PHP session files containing the string upload_progress_pwn.

🧹 If found: isolate the gateway and open an investigation.

⚙️ Fake Check Point component

The TSGA backdoor poses as a legitimate process.

🔎 Look for: a process or file named after the CPconfigdaemon pattern.

🧹 If found: don’t just delete it: have the device analyzed.

🧾 Gaps in the logs

The backdoor can tamper with firewall logs.

🔎 Look for: periods with no logs, especially after the logging service crashed.

🧹 If found: compare with logs kept elsewhere, if any.

🖥️ Connections to VMware

The attacker used the firewall as a stepping stone.

🔎 Look for: SSH connections from the gateway to your ESXi servers.

🧹 If found: change the passwords of VMware service accounts and check your backups.

After the fix is installed, Check Point also explains how to spot blocked attempts in the DynamicCLI service log. The vendor warns that the absence of these indicators doesn’t rule out a compromise, but their presence calls for an immediate investigation.

What each measure fixes, and what it doesn’t

Measure Blocks PHP2Shell Blocks root access Removes access already installed
Install the November Jumbo Hotfix ✔ ✔ ✖
Stop dynamic_server (temporary mitigation) ✖ ✔ ✖
Look for the indicators published by Check Point ✖ ✖ ◐
Have a compromised gateway analyzed or rebuilt ✖ ✖ ✔

✔ yes · ✖ no · ◐ helps detect, without fixing. The first three rows come from Check Point’s advisories; the last one is standard incident response practice.

Not using Check Point? The lesson applies to every firewall

This scenario repeats from one brand to the next: an exposed remote access portal, a published fix, then attacks within days. We saw it with FortiBleed at Fortinet. Three habits for a small business:

  • Know your firewall: brand, version and who receives the vendor’s security advisories.
  • Patch internet-facing devices first, in days rather than weeks.
  • Limit what the firewall can reach internally: it usually doesn’t need to log in to your virtualization servers.

How NeoTech can help

With our managed IT services, we keep an inventory of your network equipment, follow manufacturers’ advisories and schedule urgent fixes for internet-facing devices. We also provide automated 24/7 monitoring with on-call technician intervention when unusual behaviour is detected on your systems.

Book your free cyber check

In 30 minutes, we review your firewall’s brand, version and exposure with you, and what needs fixing first.

👉 Book your free cyber check

Call us at 438-476-2322 or email info@neotechcloudsolutions.com.

Our office: 2572 boul. Daniel-Johnson, office 237, Laval.

Sources

Photo: Sergei Starostin, Pexels (Pexels licence).

Leave a Reply

Your email address will not be published. Required fields are marked *