Has CVE-2026-123039 been used to get root on your Gaia gateway?
Check Point security article sk1000362, last modified on 12 November 2026, rates CVE-2026-123039 High (CVSS 3.1 7.8): a local privilege escalation to root in the Gaia DynamicCLI daemon. Check Point says it observed an active exploit against a couple of dozen customers. Check Point Research reported PHP2Shell on Mobile Access portals as the initial access, then this flaw for root. Apply the listed Jumbo takes, or the temporary mitigation, and confirm the PHP2Shell fix.
Check Point High (CVSS 3.1 7.8). Our framing: Critical by impact. Apply the listed Jumbo take, or mitigate.
Check Point security article sk1000362 rates CVE-2026-123039 High, CVSS 3.1 7.8 (vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, from the official CVE record). The article says Check Point observed an active exploit of this vulnerability against a couple of dozen customers. Check Point Research describes two waves of activity that used PHP2Shell on unpatched Mobile Access portals, then this flaw to reach root. Some first-wave intrusions were destructive. Our framing, not Check Point's rating: we treat this as Critical by impact because a local root escalation has been used after a portal compromise, and because some of those intrusions involved a wiper. CVE-2026-123039 was not in CISA's Known Exploited Vulnerabilities catalogue when we checked at 12 November 2026, 17:16 GMT. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) has been listed since 26 October 2026. Apply the Jumbo Hotfix Accumulator takes listed in the article where a take exists, or use the temporary mitigation, and confirm the PHP2Shell portal fix as well. See our PHP2Shell threat page.
By Simon Phillips, CTO. Reviewed by Oliver Legg, Head of SOC and IR. Last updated 12 November 2026, 18:22 GMT.
At a Glance
Based on Check Point security article sk1000362, the Check Point Research post, the Jumbo resolved-issues lists, the official CVE and NVD records, and CISA's KEV catalogue, all checked at 12 November 2026, 17:16 GMT. Last updated 12 November 2026, 18:22 GMT.
Check Point High (CVSS 3.1 7.8); Critical by impact is our framing
Check Point rates CVE-2026-123039 High. The official CVE record gives CVSS 3.1 7.8, vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, and lists CWE-862 (Missing Authorization) and CWE-732 (Incorrect Permission Assignment for Critical Resource). The NVD record, status Received when we checked, repeats that Check Point score as Secondary and had not published its own analysis. Our framing, labelled separately: Critical by impact, because this local root escalation has been used after PHP2Shell on Mobile Access portals, and Check Point Research reported destructive activity in the first wave.
Observed exploitation; not in KEV
sk1000362 says: Check Point observed an active exploit of this vulnerability against a couple of dozen customers. Check Point Research, in a post dated 12 November 2026, described a first wave from 30 October 2026 against Israeli organisations, some of it destructive, and a second wave from 2 November 2026 that was broader, with no evidence of destructive activity in that second wave and no clear sector preference. CVE-2026-123039 was not in CISA's Known Exploited Vulnerabilities catalogue when we checked at 12 November 2026, 17:16 GMT. That catalogue (2026.11.10) was released at 19:03 GMT on 10 November 2026. Recheck KEV. We do not treat the absence from KEV as a statement that there has been no exploitation. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) was added to KEV on 26 October 2026, with a due date of 29 October 2026, and known ransomware campaign use listed as Unknown.
Gaia R82.20 to R81, as listed in sk1000362
sk1000362 lists affected products as Check Point Force Firewalls, Check Point Management and Log Servers, Multi-Domain Security Management and Multi-Domain Log Server, and Maestro Orchestrator. Non-affected products are Check Point Spark Firewalls and Smart-1 Cloud. Affected versions in the article are R82.20, R82.10, R82, R81.20, R81.10 and R81. The article properties mark R81 and R81.10 as end of support. The official CVE record is narrower: it names Quantum Security Gateway and Quantum Security Management, and lists affected as R82.20 with Jumbo Take 10 or below, R82.10 with Jumbo Take 50 or below, R82 with Jumbo Take 130 or below, and R81.20 with Jumbo Take 173 or below. It does not name R81, R81.10, Maestro Orchestrator, or Multi-Domain products in that affected block. We show both lists and do not drop the products or versions that appear only in the security article.
Listed Jumbo takes; no take yet shown for R81.20 on the public list
sk1000362 says the issue is resolved in Jumbo Hotfix Accumulator for R82.20 starting from Take 14, R82.10 starting from Take 52, R82 starting from Take 132, and R81.20 starting from Take 174. The public resolved-issues pages confirm Take 132 (R82), Take 52 (R82.10) and Take 14 (R82.20), each released on 12 November 2026, and those takes also list the PHP2Shell CVEs (referring to sk1000302). The same pages do not list intermediate takes (for example R82 Take 131) as fixed; we do not treat a take as fixed unless a source says so. For R81.20, the article and the CVE record (Take 173 or below affected) describe a fix starting at Take 174, but the public R81.20 resolved-issues list still showed Take 173, released 12 October 2026, as the latest take when we checked, and it did not list CVE-2026-123039. No fixed take is listed for R81.10 or R81. For those trains, use the temporary mitigation and plan an upgrade. A temporary mitigation is to stop dynamic_server and prevent it from restarting, as described in the article; that causes Dynamic CLI commands listed in sk144112 to fail.
CISA added PHP2Shell, CVE-2026-109618 and CVE-2026-109619, to the Known Exploited Vulnerabilities catalogue, with a due date of 29 October 2026.
Check Point Research says a first wave of activity began against Israeli organisations, using PHP2Shell on unpatched Mobile Access portals and then CVE-2026-123039 to reach root. Some of that activity was destructive.
Check Point Research says a second, broader wave began, including some previously targeted Israeli organisations and organisations worldwide, with no evidence of destructive activity in that second wave and no clear sector preference.
Date Created on Check Point security article sk1000362.
The Check Point CNA published the official CVE record for CVE-2026-123039.
NVD published its record. Status was still Received when we checked.
Jumbo takes that include this CVE were released for R82 (Take 132), R82.10 (Take 52) and R82.20 (Take 14). Those takes also list the PHP2Shell CVEs. sk1000362 shows Last Modified 12 November 2026. Check Point Research published its post the same day.
We checked sk1000362, the Check Point Research post, the Jumbo resolved-issues lists for R82, R82.10, R82.20 and R81.20, the official CVE and NVD records, and CISA's KEV catalogue 2026.11.10. CVE-2026-123039 was not listed in KEV. Recheck those sources.
What Check Point says
sk1000362 describes a local privilege escalation to root in the DynamicCLI daemon. The process dynamic_server listens on a local control socket at /tmp/dynamic_socket. The article says the socket is world-writable (mode 0777) and does not authenticate the connecting process, and that command strings received on the socket are executed as root. The article's wording is: any authenticated local user can run arbitrary commands as root by writing a single request to the socket. It also states that the issue is a local privilege escalation and requires the attacker to already have local code execution on the appliance. The official CVE record uses the same description in slightly different words: an authenticated local user can send a command to the socket and have it executed as root. We do not add further technical detail.
Critical by impact is our framing
Check Point rates this High, CVSS 3.1 7.8, which matches a local privilege escalation that needs an existing local foothold. Our framing, labelled separately from that vendor rating: Critical by impact. We use that wording because Check Point has reported observed exploitation against a couple of dozen customers, Check Point Research has documented use of this flaw to reach root after PHP2Shell on Mobile Access portals, and some first-wave intrusions were destructive, including a wiper left on connected VMware ESXi hosts.
PHP2Shell was the initial access in the documented waves
Check Point Research says the documented waves began with scanning and exploitation of unpatched Check Point Security Gateways through Mobile Access portals, using PHP2Shell (CVE-2026-109618 and CVE-2026-109619), then CVE-2026-123039 for root. Those PHP2Shell CVEs have been in CISA KEV since 26 October 2026. The 12 November Jumbo takes for R82, R82.10 and R82.20 that fix CVE-2026-123039 also list the PHP2Shell CVEs, referring to sk1000302. Still confirm that the portal itself is patched. See our PHP2Shell threat page. We have not edited that page as part of this update.
Where the version lists differ
Use sk1000362 as the vendor product list: Force Firewalls, Management and Log Servers, Multi-Domain Security Management and Multi-Domain Log Server, and Maestro Orchestrator, on R82.20, R82.10, R82, R81.20, R81.10 and R81. Spark Firewalls and Smart-1 Cloud are not affected. The official CVE record lists only Quantum Security Gateway and Quantum Security Management, with take-level ranges (R82.20 Take 10 or below, R82.10 Take 50 or below, R82 Take 130 or below, R81.20 Take 173 or below), and does not name R81, R81.10, Maestro Orchestrator or the Multi-Domain products in that block. For R81.20, the article says the fix starts at Take 174, but the public resolved-issues page had not published Take 174 when we checked. We do not invent a release date for that take.
What to Do in the Next 24 Hours
Proactive on the left. Reactive on the right. Vendor steps and our advice are labelled separately.
Apply the listed Jumbo take, or mitigate, and confirm PHP2Shell is patched
- Check Point: apply the Jumbo Hotfix Accumulator take listed in sk1000362 where one exists (R82.20 Take 14+, R82.10 Take 52+, R82 Take 132+, and R81.20 Take 174+ as named in the article). Confirm the socket is mode 0660 after the fix.
- Check Point: on R81.10 and R81, there is no listed fixed take. Use the temporary mitigation (stop dynamic_server and prevent it from restarting) and plan an upgrade. Stopping the process breaks Dynamic CLI commands listed in sk144112.
- Check Point: run the IOC greps published in sk1000362 against /var/log/dynamicCli.log on each Force Firewall or cluster member, as written in the article.
- Our advice: confirm PHP2Shell is patched on every Mobile Access portal, and find every internet-exposed portal and restrict it until both issues are fixed. See our PHP2Shell threat page.
- Our advice: after patching, confirm /tmp/dynamic_socket is 0660 not 0777. Lock down SSH from gateways to ESXi and review vpxuser.
Hunt for the artefacts Check Point has published
- Our advice: look for the artefacts published by Check Point and Check Point Research. These are things to look for, not attack steps.
- Our advice: review /var/log/dynamicCli.log for commands that do not use the standard Clish wrapper, and look for zz*.tpl or challenge_render.tpl among portal login templates.
- Our advice: look for /tmp/.up.tpl, /tmp/CPconfigdaemon, /tmp/.bd.log, slot_CPconfigdaemon, /lib/libcpfwcommon.so, a listener on TCP 11072 or /tmp/.p_sock, and on ESXi /tmp/des and DREAM_ANNEXATION.txt.
- Our advice: if you find signs of compromise, isolate the gateway, rotate gateway credentials and VPN secrets, rebuild from known-good media, and inspect connected ESXi hosts and the management server.
Proactive: Vendor Steps, Then Ours
Check Point's Jumbo take or temporary mitigation first, then our advice for finding every exposed Mobile Access portal and confirming the fix. Vendor steps and our advice are labelled separately.
Apply the listed Jumbo take where one exists
Vendor path: sk1000362 says the issue is resolved in Jumbo Hotfix Accumulator for R82.20 starting from Take 14, R82.10 starting from Take 52, R82 starting from Take 132, and R81.20 starting from Take 174. The public resolved-issues pages confirm the R82, R82.10 and R82.20 takes, each released on 12 November 2026. For R81.20, follow the article, but be aware that the public resolved-issues list had not yet published Take 174 when we checked. Those confirmed 12 November takes also list PHP2Shell (sk1000302). Confirm the portal fix as well.
On R81.10 and R81, mitigate and plan an upgrade
Vendor path: sk1000362 lists R81.10 and R81 as affected and does not give a fixed Jumbo take for either train. The article properties mark both as end of support. Use the temporary mitigation below and plan an upgrade to a train that has a listed fix.
Temporary mitigation, if you cannot patch yet
Vendor path, from sk1000362: stop the dynamic_server process and prevent it from restarting. The article says to run dbset process:dynamic_server and then dbset :save. To re-enable it, run dbset process:dynamic_server t and then dbset :save. Stopping the process causes the Dynamic CLI commands listed in sk144112 to fail. To check whether the process is running, the article says to use Expert mode and run ps auxw | grep -v grep | grep 'dynamic_server'.
After the fix, confirm the socket mode
Vendor path: after the fix is installed, sk1000362 says the output of ls -l /tmp/dynamic_socket should show srw-rw---- root config (0660), not srwxrwxrwx (0777).
Review DynamicCLI logs as the article describes
Vendor path: Check Point advice in sk1000362 includes running the IOC greps published in that article against /var/log/dynamicCli.log on each Force Firewall or cluster member. Those greps look for Received = lines that do not use the standard Clish wrapper, for the uncommon Received = #return_value# system() sink, and for a keyword list that the article associates with exploitation attempts. After the fix, the article also publishes a grep for Rejected connection from unauthorized uid. Use the commands as written in the article; this page is not a substitute for them.
Apply the Jumbo take now, and confirm PHP2Shell is patched
Our advice: where a listed Jumbo take exists, apply it now. On R82, R82.10 and R82.20, the 12 November takes that fix this CVE also list PHP2Shell; still confirm the Mobile Access portal is patched. On R81.20, treat Take 174 as the fix named in sk1000362, and check the public Jumbo list before you assume that take is already published. On R81.10 and R81, apply the temporary mitigation and plan an upgrade. See our PHP2Shell threat page.
Find every internet-exposed Mobile Access gateway and restrict it until it is patched
Our advice: the documented waves used internet-facing Mobile Access portals as the initial access. Inventory every Check Point Security Gateway that publishes a Mobile Access portal, including those you host for clients. Until PHP2Shell and this DynamicCLI issue are both fixed, restrict those portals so they are not reachable from the open internet if you can do so.
After patching, confirm the DynamicCLI socket is 0660, not 0777
Our advice: this is also the vendor confirmation step. After you install the Jumbo take, check ls -l /tmp/dynamic_socket and confirm it shows srw-rw---- root config (0660), not srwxrwxrwx (0777).
Lock down SSH from gateways to ESXi, and review vpxuser
Our advice: Check Point Research documented later-stage use of SSH as vpxuser from a compromised gateway to connected VMware ESXi hosts, followed by a wiper in some first-wave cases. Restrict SSH from Gaia gateways to ESXi management interfaces, and review the vpxuser account and any trust between those systems. This is our advice, not a Check Point configuration requirement in sk1000362.
Free Detection Pack
Built by the CybaVerse threat hunt team for businesses, internal IT teams and MSPs. Check exposure offline and hunt for signs of misuse. Everything is read-only.
check-checkpoint-gaia.sh
Read-only, offline checker. Our advice: run it on exported files (cpinfo output, an inventory CSV, listings and log copies), never on the gateway itself. Collect those inputs with your own change process and feed them in offline. The checker never contacts Check Point or a gateway, never writes, and never prints matched log text.
bash check-checkpoint-gaia.sh --version R82.10 --take 50
# Saved cpinfo -y all output (sk83860)
bash check-checkpoint-gaia.sh --cpinfo saved-cpinfo-y-all.txt --review dynamicCli.log --review listing.txt
# Estate inventory (CSV header: name,product,version,take)
bash check-checkpoint-gaia.sh --inventory gaia.csv --review dynamicCli.logCheck-CheckPointGaia.ps1
The same checks in PowerShell 7, with identical output and exit codes. It is also read-only and offline. Our advice is the same: run it on exported files, never on the gateway itself.
pwsh -File Check-CheckPointGaia.ps1 -Version R82.10 -Take 50 -Review listing.txt
pwsh -File Check-CheckPointGaia.ps1 -Cpinfo saved-cpinfo-y-all.txt -Review dynamicCli.logKQL and Sigma
14 KQL hunts. Vendor IOC: V1, V1b, and V2 to V8 (attacker IPs, SHA-256 values, file paths and names, sk1000362 dynamicCli.log checks, TCP 11072, ESXi SSH as vpxuser, and ESXi wiper artefacts). Our pattern: O1 to O5 (inventory of Check Point log sources, SSH from gateways to ESXi, internal scanning from a gateway, segfault bursts, and new public sources to Mobile Access portals since 30 October 2026). 7 Sigma rules, all vendor IOC, with Kusto conversions included. None of the KQL has been run against a live tenant. Only the two Linux process-creation and file-event Sigma rules convert on Microsoft pipelines; the pack README sets out that gap.
Verdicts
- PATCHED / NOT AFFECTEDThe Jumbo take is at or above the first fixed take named in sk1000362, or the product is Spark or Smart-1 Cloud, which that article says are not affected. Not proof the appliance was not accessed before the fix.
- VULNERABLEThe take is below the first fixed take, or a reviewed listing shows /tmp/dynamic_socket as srwxrwxrwx (0777).
- NO FIXR81.10 or R81, for which sk1000362 names no fixed take. Apply the temporary mitigation and plan an upgrade.
- UNKNOWNThe version, product or take is missing, malformed or not listed.
- IOC REVIEWA published IOC, or one of our two pattern checks, matched in a review file. The checker prints labels, counts and line numbers, not the matched text.
Exit codes
| Code | Meaning |
|---|---|
| 0 | PATCHED / NOT AFFECTED |
| 1 | VULNERABLE |
| 2 | NO FIX |
| 3 | UNKNOWN |
| 4 | Usage or read error |
| 5 | IOC REVIEW |
Worst wins: 5, then 1, then 2, then 3, then 0. The full pack zip contains 42 files: 14 KQL hunts, 7 Sigma rules and their Kusto conversions, both checkers, tests and the README. Download links were checked at 12 November 2026, 18:22 GMT.
Know the limits
- Our advice: run the checker on exported files, never on the gateway itself. Both checkers are read-only and offline. They never fetch, never write, never contact Check Point or a gateway, and never print matched log text.
- None of the KQL has been run against a live tenant. Tune it before relying on it. Gaia gateways do not run Defender for Endpoint; the Device hunts cover other hosts only. Whether Gaia, dynamicCli.log or ESXi messages reach Sentinel is unverified for your connectors.
- Vendor IOC hunts search for indicators Check Point published. Our pattern hunts are labelled separately.
- Only the two Linux Sigma rules (process creation and file event) convert on the Microsoft pipelines (Defender, Sentinel ASIM and Azure Monitor). The two firewall rules and the three Check Point or ESXi rules have no table mapping there. The pack README describes that gap; use the matching KQL hunts (V1, V5, V6, V7 and V8) instead.
- A PATCHED result or a clean hunt is not proof the gateway was not accessed, and patching does not remove an implant.
What is in the pack
| File | What it does |
|---|---|
| check-checkpoint-gaia.sh | Read-only checker for Linux and macOS (bash) |
| Check-CheckPointGaia.ps1 | The same checker in PowerShell 7 |
| KQL (14 hunts) | Vendor IOC V1, V1b and V2 to V8; our pattern O1 to O5 |
| Sigma (7 rules) | Vendor IOC; only the two Linux process and file rules convert on Microsoft pipelines; Kusto conversions included |
| tests/ | Fixtures and tests (in the full pack) |
| README.md | Verified facts, Check Point advice versus ours, limits and usage |
Reactive: How to Hunt (Our Advice)
These hunts are based on indicators published by Check Point and Check Point Research. They are things to look for, not attack steps. The KQL in the pack has not been run against a live tenant. Run the pack checker on exported files, never on the gateway itself; that last point is our advice. CybaOps can run a hunt across the Check Point gateways you manage.
Look for these artefacts, as documented by Check Point
Our advice: treat the items below as things to look for, not as a description of how to carry out an attack. They come from sk1000362 and from the Check Point Research post. Look in /var/log/dynamicCli.log for commands that do not use the standard Clish wrapper described in the article. On Mobile Access portals, look for unexpected zz*.tpl files, or challenge_render.tpl, among the portal login templates. Look for /tmp/.up.tpl, /tmp/CPconfigdaemon, /tmp/.bd.log, a boot-persistence entry for slot_CPconfigdaemon, and /lib/libcpfwcommon.so. Check Point Research also documented a listener on TCP 11072 or a socket at /tmp/.p_sock. Check Point Research documented PHP session files containing upload_progress_pwn under /opt/CPcvpn-R81.20/tmp/. That is the documented location. Our suggestion, not a Check Point indicator: you may also look in equivalent directories on other versions. Bursts of Apache or PHP segfaults were noted as well. On connected ESXi hosts, look for /tmp/des and DREAM_ANNEXATION.txt.
Network indicators from Check Point Research
Our advice: These IPv4 addresses appear in the Check Point Research indicators table. They are defanged so they do not become links: 130.94.19[.]204 and 130.94.19[.]168. Check those addresses in firewall, proxy and DNS logs. Do not treat them as a complete list.
File hashes from Check Point Research
Our advice:
SHA-256 hashes below are the eight rows copied from the Check Point Research indicators table. The table labels the wiper sample destory_v6, which is a typo for destroy_v6. We keep that label so the hash can be matched to the post.
| SHA-256 | Name in the Check Point Research table |
|---|---|
edb3e92eb7bda7413a09edcc4b1ba3cbed4bcdf42808a8abce63b6e4c3fda2b3 | tpl webshell |
4171b521fa6441382aa2fa014a08e18ff9a6e0ab6096c9144072bf46b37a2ec8 | slot_CPconfigdaemon |
d7549671c7189979f0624ec52dad9ea6a707d23146e3585ab8f8c4720eca0c63 | CPconfigdaemon |
3b51080a909023f7d484e2443740b572307ce0054eb9e32d98f0a06bfcd2db90 | gogo |
c7d9477309fac6c638a1128442056a242de086996add8cb49cd6496c36003237 | destory_v6 (wiper) |
0522937c0c0337be54fe25493539e5f5f8ceb9742c980aaff1cfc9515f3a96f7 | DREAM_ANNEXATION.txt |
ee16e1695711b9d60c62925fcfb2fe1a29c18ae26565bc05410a14e16d2a39d7 | philistine |
fb1a6235eb6bce8c9ec8cd8bb85f17c9c2bde8ecb45b7a243a30ceadf26654da | libdssafe.so |
The Check Point Research indicators table has eight SHA-256 rows. The last two, philistine and libdssafe.so, are samples of the earlier related framework that the post compares TSGA and TSProxy with. The post does not say those two samples were found on the gateways in this intrusion.
If you find signs of compromise
Our advice: isolate the affected gateway, keep logs and images, rotate gateway credentials and VPN secrets, and rebuild from known-good media. Check any connected VMware ESXi hosts and the management server. Installing a Jumbo take stops new use of this flaw. It does not undo access, webshells, backdoors or wiper activity that already happened.
If you find signs of compromise (our advice)
- Isolate the affected gateway and keep logs, disk images and memory captures where you can.
- Rotate gateway credentials and VPN secrets, and review administrator accounts.
- Rebuild the gateway from known-good vendor media, then apply the listed Jumbo take before returning it to service.
- Inspect connected VMware ESXi hosts for /tmp/des, DREAM_ANNEXATION.txt, unexpected SSH as vpxuser, and signs of a wiper.
- Inspect the management server and any other gateways or portals in the same estate.
- Start incident response for every environment that gateway could reach.
Patched does not mean clean
Installing a listed Jumbo take, or applying the temporary mitigation, stops new use of this DynamicCLI flaw. It does not remove webshells, backdoors or persistence that were already planted, and it does not undo damage already done on a connected ESXi host. Hunt the period before you patched.
Check Point Gaia CVE-2026-123039 FAQ
Short answers based on Check Point security article sk1000362, the Check Point Research post, the Jumbo Hotfix Accumulator resolved-issues lists, the official CVE record, the NVD record, and CISA's Known Exploited Vulnerabilities catalogue. We checked those sources at 12 November 2026, 17:16 GMT.
What is CVE-2026-123039?
It is a local privilege escalation to root in the Gaia DynamicCLI daemon, documented in Check Point security article sk1000362. The process dynamic_server listens on a world-writable local socket at /tmp/dynamic_socket and, according to the article and the official CVE record, does not authenticate the connecting process. Command strings received on that socket are executed as root. The article says any authenticated local user can run arbitrary commands as root by writing a single request to the socket, and that the attacker must already have local code execution on the appliance. The official CVE record uses the same description in slightly different words. The CVE record was published by the Check Point CNA at 14:02 GMT on 12 November 2026.
What is the severity?
Check Point rates it High. The official CVE record gives CVSS 3.1 7.8, vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, and lists CWE-862 and CWE-732. The NVD record, status Received when we checked, repeats that score as Secondary and had not published its own analysis. Our framing, labelled separately: Critical by impact, because this local root escalation has been used after PHP2Shell, and some first-wave intrusions were destructive.
Which products and versions are affected?
sk1000362 lists Check Point Force Firewalls, Management and Log Servers, Multi-Domain Security Management and Multi-Domain Log Server, and Maestro Orchestrator, on versions R82.20, R82.10, R82, R81.20, R81.10 and R81. Check Point Spark Firewalls and Smart-1 Cloud are not affected. R81 and R81.10 are marked end of support in the article properties. The official CVE record lists Quantum Security Gateway and Quantum Security Management, with Jumbo take ceilings of Take 10 or below (R82.20), Take 50 or below (R82.10), Take 130 or below (R82), and Take 173 or below (R81.20). It does not list R81, R81.10, Maestro Orchestrator or the Multi-Domain products in that affected block. We show both lists.
How do we fix it, and is there a temporary mitigation?
sk1000362 says the fix is in Jumbo Hotfix Accumulator for R82.20 starting from Take 14, R82.10 starting from Take 52, R82 starting from Take 132, and R81.20 starting from Take 174. The first three of those takes were released on 12 November 2026 and are listed on the public resolved-issues pages. Take 174 for R81.20 was named in the article, but was not on the public R81.20 resolved-issues list when we checked. No fixed take is listed for R81.10 or R81. The temporary mitigation is to stop dynamic_server and prevent it from restarting, using the dbset commands in the article; that causes Dynamic CLI commands listed in sk144112 to fail.
Is it being exploited, or in CISA KEV?
Yes, Check Point has reported observed exploitation, but CVE-2026-123039 was not in CISA's Known Exploited Vulnerabilities catalogue when we checked at 12 November 2026, 17:16 GMT. sk1000362 says Check Point observed an active exploit of this vulnerability against a couple of dozen customers. Check Point Research described two waves, from 30 October and 2 November 2026. Recheck KEV. PHP2Shell (CVE-2026-109618 and CVE-2026-109619) has been in KEV since 26 October 2026.
How does this relate to PHP2Shell?
Check Point Research says the documented waves used PHP2Shell on unpatched Mobile Access portals as the initial access, then CVE-2026-123039 to reach root. The 12 November Jumbo takes for R82, R82.10 and R82.20 that fix this CVE also list the PHP2Shell CVEs. Still confirm the portal is patched. Our PHP2Shell write-up is at /threats/php2shell-checker.
What should we look for?
Look for the artefacts published by Check Point and Check Point Research. That includes unexpected commands in /var/log/dynamicCli.log, zz*.tpl or challenge_render.tpl among portal login templates, /tmp/.up.tpl, /tmp/CPconfigdaemon, /tmp/.bd.log, slot_CPconfigdaemon in boot persistence, /lib/libcpfwcommon.so, a listener on TCP 11072 or /tmp/.p_sock, PHP session files containing upload_progress_pwn under /opt/CPcvpn-R81.20/tmp/ (the documented location), bursts of Apache or PHP segfaults, and on ESXi /tmp/des and DREAM_ANNEXATION.txt. Check Point Research also published eight SHA-256 hashes, including two samples of an earlier related framework that the post compares with TSGA and TSProxy, and the defanged addresses 130.94.19[.]204 and 130.94.19[.]168. These are things to look for, not attack steps.
What should we do first?
Follow Check Point first: apply the listed Jumbo take where one exists, or use the temporary mitigation on trains with no listed take, and confirm PHP2Shell is patched on any Mobile Access portal. Our advice on top: find every internet-exposed Mobile Access gateway and restrict it until it is patched; after patching, confirm the DynamicCLI socket is mode 0660 not 0777; lock down SSH from gateways to ESXi and review vpxuser; and if you find signs of compromise, isolate, rotate gateway credentials and VPN secrets, rebuild from known-good media, and inspect connected ESXi hosts and the management server.
Who is this relevant to?
Anyone who runs the Check Point products listed in sk1000362, especially Security Gateways that publish a Mobile Access portal, and anyone who has ESXi hosts reachable over SSH from those gateways. Management and log servers, Multi-Domain systems and Maestro Orchestrator are also in the article's affected product list.
Need help checking every Check Point gateway you manage?
CybaOps monitors your servers, endpoints and cloud workloads, whether that's your own business or your clients'. UK-based analysts monitor alerts 24/7, run these threat hunts and act on pre-approved response actions, and CybaOps drives remediation through to a verified fix, so proactive checks and reactive response happen in one place.
Sources
- Check Point: security article sk1000362, Local privilege escalation to root in the DynamicCLI daemon via local world-writable control socket, CVE-2026-123039 (Date Created 8 November 2026, Last Modified 12 November 2026; checked at 12 November 2026, 17:16 GMT)
- Check Point Research: PHP2Shell Exploitation on Check Point Gateway (dated 12 November 2026; checked at 12 November 2026, 17:16 GMT)
- Check Point: Jumbo Hotfix Accumulator for R82, All Resolved Issues (Take 132 released 12 November 2026, includes CVE-2026-123039 and PHP2Shell CVE-2026-109618 / CVE-2026-109619; checked at 12 November 2026, 17:16 GMT)
- Check Point: Jumbo Hotfix Accumulator for R82.10, All Resolved Issues (Take 52 released 12 November 2026, includes the same CVE families; checked at 12 November 2026, 17:16 GMT)
- Check Point: Jumbo Hotfix Accumulator for R82.20, All Resolved Issues (Take 14 released 12 November 2026, includes the same CVE families; checked at 12 November 2026, 17:16 GMT)
- Check Point: Jumbo Hotfix Accumulator for R81.20, All Resolved Issues (latest take shown was Take 173, released 12 October 2026; Take 174 and CVE-2026-123039 were not listed when checked at 12 November 2026, 17:16 GMT)
- Check Point: sk144112, Dynamic CLI: Enhancing Gaia Clish with new Expert mode commands (referenced from sk1000362 for the impact of stopping dynamic_server)
- Check Point: sk1000302, the PHP2Shell article referenced from the Jumbo resolved-issues lists for CVE-2026-109618 and CVE-2026-109619
- CVE record: CVE-2026-123039 (Check Point CNA; datePublished 14:02 GMT on 12 November 2026; checked at 12 November 2026, 17:16 GMT)
- NVD: CVE-2026-123039 (published 14:17 GMT on 12 November 2026, status Received when checked at 12 November 2026, 17:16 GMT)
- CISA: Known Exploited Vulnerabilities catalogue (catalogue 2026.11.10, released 19:03 GMT on 10 November 2026; checked at 12 November 2026, 17:16 GMT)