Check Point says a 7.8 root flaw in Gaia was step two of gateway attacks that ended in a wiper

A 7.8 score for step two of a chain that ended in a wiper

Check Point's advisory sk1000362, last modified 2026-11-12, gives CVE-2026-123039 a CVSS score of 7.8 and says Check Point "observed an active exploit of this vulnerability against a couple of dozen customers". The same advisory says the flaw is a local privilege escalation that "requires the attacker to already have local code execution on the appliance". Check Point Research's report PHP2Shell Exploitation on Check Point Gateway, published the same day, says how attackers got that foothold: through the Mobile Access portal, with PHP2Shell, before using this flaw to reach root. In the one intrusion the report investigated, the chain went on to webshells, a persistent backdoor, SSH to a VMware ESXi host and a wiper called destroy_v6. The advisory never mentions PHP2Shell, and neither page gives a count of victims.

What this does not establish. A score of 7.8 describes a local flaw taken alone, and the CVE record's vector says exactly that (local attack vector, low privileges required). It does not describe what the report says the attackers did with it. Neither page says who ran the campaign with high confidence, how many systems were wiped, which Check Point build closes the first step on a Mobile Access gateway, or how many customers were hit in all: "a couple of dozen" is the advisory's phrase and this article does not turn it into a number. Whether CISA lists CVE-2026-123039 was not read.

Time stamps. The advisory page was saved by the newsroom as a PDF at 11:20 UTC on 13 November 2026 (the file's own creation time) and the report page was saved about the same time; the CVE record was fetched at about 11:24 UTC the same day. The report's own page data gives its publication as 13:56 UTC on 12 November 2026 and the CVE record gives its publication as 14:02 UTC the same day. Anything Check Point or anyone else changed after those reads is not in this article. Check Point sells the gateways and wrote both the advisory and the report, so its account of exposure, such as "unpatched" gateways and "a couple of dozen customers", is its own.

What the report says happened, in order

The report says that, beginning on 30 October 2026, an attacker scanned and exploited "organizations with unpatched Check Point Security Gateways", using Mobile Access portals with PHP2Shell as initial access followed by CVE-2026-123039. It describes two waves. The first, on 30 October, targeted Israeli organisations and included destructive activity against some of them. A broader second wave on 2 November, three days later (derived), targeted organisations across several countries and sectors, with no evidence of destructive activity. The report adds that neither wave showed a clear sector preference.

In the intrusion it investigated, the order was: PHP session files carrying an exploitation marker appeared on the gateway on 30 October, and the portal's web workers logged hundreds of segmentation faults. The attacker then escalated from the portal service account to root through the DynamicCLI interface, wrote PHP webshells into the directory the portal uses to build its login pages, and started a standalone backdoor the report calls TSGA, which carries an embedded networking library called TSProxy. From the gateway the attacker ran a scanner called gogo, moved over SSH to a VMware ESXi host using a service account, staged the destroy_v6 wiper there and ran it, and left note files named DREAM_ANNEXATION.txt.

Zoom

The wiper ran on the ESXi host, not on the gateway. That matters for the checklist below. The report describes what destroy_v6 does as: it recursively deletes files in a target directory, by default overwrites them with zeros first, and writes the note file into each directory it processes. The report does not say how many hosts or files were destroyed.

The flaw as the advisory words it, and what each version gets

The advisory says Gaia's dynamic CLI is served by a root process, dynamic_server, listening on a local socket at /tmp/dynamic_socket. On affected products the socket is created world writable with no authentication of the connecting process, and the process runs whatever command string it receives as root. In the advisory's words, "any authenticated local user can run arbitrary commands as root by writing a single request to the socket". The CVE record files it under CWE-862 (missing authorization) and CWE-732 (incorrect permission assignment for a critical resource).

The fix, as the advisory prints it, is in Jumbo Hotfix Accumulators from a stated Take on four release lines. Two lines the advisory lists as affected, R81 and R81.10, are marked end of support (EOS) and have no hotfix printed. The CVE record gives a second, shorter list: it names only two products and the four lines that have hotfixes, each as "Take N or below". The two lists do not meet.

Reading the table: the advisory lists six affected versions and prints a fix for four of them (two have none, derived). Where the advisory says "starting from" one Take and the record says "or below" an earlier Take, a gateway on the Takes in between is covered by neither sentence. That is five Take numbers across three release lines (derived: 3 + 1 + 1 + 0). It is probably a numbering convention and not a hole, but neither page says so. The advisory's products also differ from the record's: the advisory lists Force Firewalls, Management and Log Servers, Multi-Domain Security Management and Multi-Domain Log Server, and Maestro Orchestrator as affected and Spark Firewalls and Smart-1 Cloud as not affected; the record names only Quantum Security Gateway and Quantum Security Management. The advisory prints no per product fix, so whether a Maestro or Scalable Platform build has its own Take is not stated.

Zoom

What a 7.8 measures, and what it leaves out

The CVE record, whose issuer is Check Point (its own CNA record), prints CVSS 3.1 vector (AV:L, AC:L, PR:L, UI:N, S:U, C:H, I:H, A:H) with a base score of 7.8 and severity High. The advisory prints the score without the vector and also tags the alert High. Every letter of the vector is a statement about the flaw alone. Local access is required, privileges required are low, and the impact on confidentiality, integrity and availability is high.

The friendly label here is "local privilege escalation". It reads as a flaw that matters only after something else has already gone wrong, and the advisory says as much. The report shows what that something else was in this campaign: a flaw in a web portal that a stranger on the internet can reach. Once a gateway has an internet facing portal bug, a local root flaw is the second half of a remote root chain. That is this site's reading of the two pages together, not a sentence in either of them. The score is correct for the flaw, and it is not a score for the chain.

Who Check Point says did it: it does not say with confidence

The report links the two implants, TSGA and TSProxy, to a malware family it calls PhiliKit, which it says was previously reported in attacks on Ivanti VPN appliances and which ESET associated with a group it names UNC5221, described as China nexus. It also says the gogo scanner has been reported in connection with Chinese nexus actors, that the attacker's infrastructure sat on a VPS provider previously associated with such actors, and that scanning was concentrated between 00:00 and 09:00 UTC, which it says matches 08:00 to 17:00 in China. Then it sets out what does not fit: a destructive operation, a focus on Israel with a note referring to the Israeli Palestinian conflict, and a family name derived from an internal name. Its conclusion is "the evidence does not allow us to assess with high confidence the true nature of this operation".

It lists scenarios that remain plausible: the identified actor ran the whole campaign, acted only as an initial access broker, or took part in a false flag operation, and the destructive activity may have been a smoke screen. This article therefore names no actor as responsible. Shared tooling is evidence of shared tooling, not of who was at the keyboard.

The note the wiper left uses the Dream Security brand. The report says Dream had recently published research on PHP2Shell exploitation of Palo Alto Networks devices by China nexus actors, and that this raises the possibility of retaliation, but "the available evidence does not establish a clear motive". A brand on a note is not authorship, and the report does not say Dream had any part in the attack; Dream is not a party at fault here. This site's earlier briefing on a Dream report about PHP2Shell is a separate event; the Check Point report does not link it and this build did not check whether it is the research Check Point means.

Where the sources differ

The PHP fix date comes from this site's earlier work, not from Check Point. The report says gateways were "unpatched" and its introduction says the activity began about a week after a security fix, but it does not name the fix or the Check Point build that carries it. This site's earlier briefings on PHP2Shell are the emergency fixes, CISA's listing and Palo Alto's advisory.

What Check Point states, and what it does not

What to do, in order

Check Point's own steps first, as the advisory prints them. Apply the Jumbo Hotfix Accumulator at or above the printed Take for your release line. If you cannot yet, stop the dynamic_server process and prevent its restart with the printed dbset commands, accepting that the Dynamic CLI commands listed in sk144112 will fail. Check whether the process is running. Run the three searches of the Dynamic CLI log for commands that do not use the expected wrapper. After patching, search the same log for rejected connections, and confirm the socket is no longer world writable. The advisory also says to correlate any burst of rejected connections with portal, web and authentication logs to find the source. The exact commands are in Technical details.

Technical details

Everything below is copied from Check Point's advisory and report as read on 13 November 2026. Line breaks in the advisory's PDF copy were joined with single spaces, so a defender should compare against Check Point's own page before running anything. The report prints one more artifact, the access key hard coded in the expanded webshell. It is left out here on purpose: it is a key to an attacker's backdoor on a victim's device, and a defender does not need it to hunt for the file.

The first block is the mitigation. The first two lines stop dynamic_server and stop it restarting. The last two lines turn it back on. An administrator runs the first pair on gateways that cannot yet take the hotfix, and the second pair only when the Dynamic CLI commands in sk144112 are needed.

dbset process:dynamic_server
dbset :save

# to re-enable the process, as printed:
dbset process:dynamic_server t
dbset :save

The second block checks whether the process is running, in Expert mode. The example output is the advisory's own example, with its own date, and is not a finding about any real gateway.

ps auxw | grep -v grep | grep 'dynamic_server'

# example output, as printed:
admin 13801 0.0 0.0 37904 7808 ? Ss Nov02 0:00 /usr/bin/dynamic_server

The third block is the indicator of compromise the advisory prints: the daemon logs every command it receives to a file, and a legitimate request uses one Clish wrapper line. A defender searches the log for any received command that does not carry the wrapper, because the advisory says such a command may mean something ran as root through the socket.

/var/log/dynamicCli.log

# legitimate wrapper, as printed:
Received = #524288# . /opt/CPshared/5.0/tmp/.CPprofile.sh >> /dev/null; export SP_DISTRIBUTE=0; set -o noglob; <Gaia binary> 2>&1

The fourth block is the three log searches the advisory says to run on each firewall or cluster member. The first finds received commands without the wrapper, the second finds use of the system() sink, which it says is uncommon or absent in legitimate traffic, and the third looks for commands commonly associated with exploitation attempts. Any hit needs investigation; the advisory does not say a hit proves compromise.

# 1. received commands without the expected wrapper
grep "Received =" /var/log/dynamicCli.log \ | grep -vF "CPprofile.sh >> /dev/null; export SP_DISTRIBUTE=0; set -o noglob;"

# 2. use of the system() sink
grep -F "Received = #return_value#" /var/log/dynamicCli.log

# 3. commands commonly associated with exploitation attempts
grep -EI "Received =.*( id;| whoami| /etc/shadow| ncat| nc -| /dev/tcp| curl | wget | base64| useradd| authorized_keys)" \ /var/log/dynamicCli.log

The fifth block is for patched gateways. The fix blocks and logs unauthenticated calls, so a rejected connection from an unexpected user id shows an escalation attempt was blocked. The advisory's example uses user id 99, which it says is nobody. The last command should show the socket as readable and writable only by root and the config group.

grep "Rejected connection from unauthorized uid" /var/log/dynamicCli.log

# example output, as printed:
[DynamicCLI]: Rejected connection from unauthorized uid 99 (pid 123456)

# expected after the fix, as printed:
ls -l /tmp/dynamic_socket
# srw-rw---- root config (0660), not srwxrwxrwx (0777)

The sixth block is the fixed builds as the advisory prints them. A gateway on a Take below the printed one for its line has no printed fix. R81 and R81.10 print none.

Jumbo Hotfix Accumulator for R82.20 starting from Take 14
Jumbo Hotfix Accumulator for R82.10 starting from Take 52
Jumbo Hotfix Accumulator for R82 starting from Take 132
Jumbo Hotfix Accumulator for R81.20 starting from Take 174

The seventh block is the file system and process traces the report prints from the intrusion it investigated. A defender searches the gateway for these names and paths. The webshell write pattern is the report's own placeholder form and is not a working command. The report calls its directory placeholder templates.

# session artifacts on the gateway, as printed:
/opt/CPcvpn-R81.20/tmp/
upload_progress_pwn

# webshell write pattern, as printed (placeholders are the report's):
printf <base64 Webshell> | base64 -d > <templates>/zz<random>.tpl
zz*.tpl
/tmp/.up.tpl
challenge_render.tpl

# backdoor start and its paths, as printed:
nohup /tmp/CPconfigdaemon >/tmp/.bd.log 2>&1 &
/tmp/CPconfigdaemon
slot_CPconfigdaemon
/lib/libcpfwcommon.so
/tmp/.bd.log

# backdoor listener and socket, as printed:
TCP port 11072
/tmp/.p_sock

# lateral movement and wiper, as printed:
vpxuser
/tmp/des wiper
destroy_v6
DREAM_ANNEXATION.txt

The eighth block is the indicator table. A defender checks file hashes on the gateway and on ESXi hosts and checks firewall and proxy logs for the two addresses. The two addresses are defanged exactly as the report prints them. The wiper's file name is spelled destory_v6 in the report's table and destroy_v6 in its text; both are copied as printed.

edb3e92eb7bda7413a09edcc4b1ba3cbed4bcdf42808a8abce63b6e4c3fda2b3  tpl webshell
4171b521fa6441382aa2fa014a08e18ff9a6e0ab6096c9144072bf46b37a2ec8  slot_CPconfigdaemon
d7549671c7189979f0624ec52dad9ea6a707d23146e3585ab8f8c4720eca0c63  CPconfigdaemon
3b51080a909023f7d484e2443740b572307ce0054eb9e32d98f0a06bfcd2db90  gogo
c7d9477309fac6c638a1128442056a242de086996add8cb49cd6496c36003237  destory_v6
0522937c0c0337be54fe25493539e5f5f8ceb9742c980aaff1cfc9515f3a96f7  DREAM_ANNEXATION.txt
ee16e1695711b9d60c62925fcfb2fe1a29c18ae26565bc05410a14e16d2a39d7  philistine
fb1a6235eb6bce8c9ec8cd8bb85f17c9c2bde8ecb45b7a243a30ceadf26654da  libdssafe.so

130.94.19[.]204
130.94.19[.]168

The report also prints the wiper's options: a target directory argument, a flag for fast deletion that skips the overwrite, and a flag for a pipe separated list of directories to exclude. It prints no working command line, and this article gives none.

The question Check Point's pages leave open

If a root flaw that needs a local account scores 7.8, and the account came from a portal bug, which of your gateways would hand an outsider that account, and who reads the Dynamic CLI log on the day it does?

Key facts