CVE-2026-123039: Check Point gateways hit via PHP2Shell, patch by 16 November

Summary. CISA added Check Point's CVE-2026-123039 to its Known Exploited Vulnerabilities (KEV) catalogue on 13 November 2026, with a federal due date of Monday 16 November and forensic triage required under BOD 26-04. The flaw (CVSS 3.1 score 7.8) is in the Gaia OS DynamicCLI daemon, which runs as root and accepts commands on a world-writable local socket without checking the caller, so any authenticated local user can run commands as root. Check Point says attackers first got in through PHP2Shell (CVE-2026-109618 and CVE-2026-109619) on internet-facing Mobile Access portals, then used this flaw to reach root; a couple of dozen unpatched systems in a single region were compromised, with activity seen from 30 October to 4 November. Affected products are Force Firewalls, management and log servers, Multi-Domain servers and Maestro Orchestrator on R82.20, R82.10, R82, R81.20 and the end-of-support R81.10 and R81. The fix is in Jumbo Hotfix Accumulator R82.20 Take 14, R82.10 Take 52, R82 Take 132 and R81.20 Take 174, the same takes that carry the PHP2Shell fix. In the intrusion Check Point Research analysed, attackers planted webshells and a backdoor, moved over SSH to a VMware ESXi host and ran a wiper; attribution is unresolved. Patch every gateway and management server now, exposed Mobile Access portals first, then run the compromise checks below.

About this article. This is for network security teams, CISOs and managed service providers in the US and UK that run Check Point gateways. On 15 November 2026 we checked the CVE records, CISA's KEV entries, BOD 26-04 and its implementation guidance, Check Point's advisories sk1000362 and sk1000302, its 12 November security advisory, the Check Point Research report and the ICO's breach guidance. Check Point revises its SK articles often, so confirm takes and mitigations there before you act. This is defensive guidance, not legal advice, and no vendor paid for inclusion. Researched with AI assistance and reviewed by our editorial team.

If you also run Ivanti, Cisco or SonicWall remote-access appliances, our roundup of five exploited VPN flaws since 13 October covers those. For PHP2Shell on ordinary web servers, see our PHP2Shell fix guide.

What is confirmed, and by whom

The table below draws on the CVE record and CISA's enrichment, the KEV catalogue, Check Point's sk1000362 and 12 November advisory, and Check Point Research.

The sources name different product sets. The CVE record lists Quantum Security Gateway and Quantum Security Management on R82.20, R82.10, R82 and R81.20. CISA's entry names Check Point Firewall, Multi-Domain Security Management Server, Scalable Platforms, Security Gateway and Security Management Server. Check Point's sk1000362 is the most complete list, and it adds the end-of-support R81.10 and R81, so work from it.

Affected products and the fixed Jumbo Hotfix takes

Two Check Point articles matter. sk1000362 covers CVE-2026-123039, the root escalation. sk1000302 covers PHP2Shell, the initial access. Their product lists overlap but differ, as the table shows.

PHP2Shell matters on a gateway only if one of these web features is on: Mobile Access Portal, Remote Access VPN with SSL Network Extender, Remote Access VPN with SAML realm authentication, Identity Awareness Captive Portal, UserCheck Portal or Zero Phishing. The attacks Check Point describes went through Mobile Access. PHP2Shell itself carries a CVSS v4.0 score of 9.2, assigned by the PHP project and repeated by Check Point.

The fixed takes come from both SKs; the affected ranges come from the CVE record.

The CVE record's ranges leave small gaps, such as R82.20 Takes 11 to 13 and R82.10 Take 51, which are neither listed as affected nor named as fixed. Do not reason about them: install the take Check Point names, or a later one.

Check Point also shipped a standalone PHP2Shell hotfix on 23 October. It implements the published PHP fix, installs on top of any Jumbo take, goes on each gateway, cluster member, security group member or standalone server, and needs a reboot. sk1000362 names only the November Jumbo takes as the fix for CVE-2026-123039, so if you installed just the October hotfix you still need the November take or the DynamicCLI mitigation. Check Point's 12 November advisory also lists two Gaia flaws with no known exploitation: CVE-2026-107484 in the Gaia Portal (CVSS 7.3) and CVE-2026-120490 (CVSS 3.8).

How the attack chain worked, as Check Point Research reports it

This is Check Point Research's account, published on 12 November, included so defenders know what to look for. It is not a reproduction guide.

• Targets. The first wave, on 30 October, hit Israeli organisations and was destructive at some of them. A broader wave on 2 November reached organisations in several countries and sectors, with no destructive activity seen.

• Initial access. Activity from 130.94.19[.]204 targeted Mobile Access portals on unpatched gateways about a week after the fix was available. Check Point found PHP session files carrying the marker upload_progress_pwn and hundreds of segmentation faults in the portal's Apache and PHP workers.

• Root. The attacker used CVE-2026-123039 to go from the portal's service account to root.

• Persistence. Webshells named zz*.tpl were written into the directory the portal uses to build its login pages, and an uploaded file was later copied in as challenge_render.tpl. A backdoor Check Point calls TSGA was launched from /tmp/CPconfigdaemon, relaunched itself as slot_CPconfigdaemon and dropped a component called TSProxy as /lib/libcpfwcommon.so. TSGA can steal configuration, persist through backups and snapshots, inject into processes and tamper with binary firewall logs.

• Lateral movement and destruction. In the intrusion analysed, the attacker ran the gogo scanner from the gateway, moved over SSH to a VMware ESXi host using the vpxuser account, and ran the destroy_v6 wiper, which leaves notes named DREAM_ANNEXATION.txt that reject ransom negotiation.

• Attribution. Check Point links TSGA and TSProxy to PhiliKit, which ESET has associated with UNC5221, but says the evidence fits several explanations, including an access broker or a false-flag operation. Its advisory calls the destructive cases ideologically motivated, while the research says the motive is not established.

Two points matter whatever the attribution. A vulnerable gateway became a beachhead into the virtualisation layer, so the blast radius was the data centre, not just the firewall. And the backdoor can tamper with firewall logs, so logs held only on the gateway cannot be trusted.

What to do before 16 November

The KEV due date binds US federal civilian agencies. For everyone else it is a fair measure of urgency, and it falls tomorrow, Monday 16 November. A practical plan from today:

For a cluster, follow Check Point's documented procedure for installing a Jumbo take on cluster members. If an end-of-support R81.10 or R81 gateway cannot move to R81.20 or later this week, apply the DynamicCLI mitigation and, on R81.10, the PHP2Shell hotfix, and restrict portal access until the upgrade is done.

If you cannot patch today: Check Point's interim mitigations

Check Point publishes one mitigation for each half of the chain. Both are temporary and both have side effects.

PHP2Shell (sk1000302). The procedure adds a block to the end of $CPDIR/web/Apache/conf/cp-httpd.conf on each gateway or cluster member, then restarts the portals with the command for your version. The block refuses multipart requests:

            <If "req('Content-Type') =~ /multipart/i">
    Require all denied
</If>
          

Back up the file first and make sure the block appears only once. Any portal function that sends multipart form data, such as file upload, will be refused. The SK has the restart commands for R82.20, R82.10, R82 and R81.20, plus separate steps for Maestro, ElasticXL and Spark Firewalls (Spark uses a different file path). Remove the block before installing the hotfix, as the SK instructs.

CVE-2026-123039 (sk1000362). The mitigation stops the dynamic_server process and keeps it from restarting. The side effect is that the Dynamic CLI commands listed in sk144112 stop working. The SK's commands, and the Expert mode check that the process has stopped:

            dbset process:dynamic_server
dbset :save
ps auxw | grep -v grep | grep 'dynamic_server'
          

After the fixed take is installed, ls -l /tmp/dynamic_socket should show srw-rw---- owned by root and group config (0660), not srwxrwxrwx (0777).

Neither mitigation removes an attacker who is already on the box. If a gateway was exposed after 23 October without the fix, run the next section's checks as well.

Compromise checks for Check Point gateways

These checks come from sk1000362, Check Point's advisory and Check Point Research. Check Point notes that no match does not rule out compromise, and that any match warrants immediate investigation.

DynamicCLI log. The vulnerable daemon logs every command it receives to /var/log/dynamicCli.log. Legitimate requests use a standard Clish wrapper; anything else may mean a command ran as root through the socket. Check Point's three checks, for each Force Firewall or cluster member:

            grep "Received =" /var/log/dynamicCli.log | grep -vF "CPprofile.sh >> /dev/null; export SP_DISTRIBUTE=0; set -o noglob;"
grep -F "Received = #return_value#" /var/log/dynamicCli.log
grep -EI "Received =.*( id;| whoami| /etc/shadow| ncat| nc -| /dev/tcp| curl | wget | base64| useradd| authorized_keys)" /var/log/dynamicCli.log
          

On a fixed gateway, blocked attempts appear as rejected connections:

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

A non-zero or unexpected UID in those lines, such as 99 (nobody), means someone tried to escalate after the patch. Match the times against portal and authentication logs.

Files and processes. Look for PHP session files containing upload_progress_pwn in the portal's temporary directories, unexpected zz*.tpl or challenge_render.tpl files in its template directory, /tmp/.up.tpl, anything named CPconfigdaemon or slot_CPconfigdaemon, /lib/libcpfwcommon.so, the Unix socket /tmp/.p_sock and a listener on TCP port 11072. Investigate at once if you find scanner or wiper tooling under /tmp or /temp.

Network and logs. Search perimeter and proxy logs for 130.94.19[.]204 and 130.94.19[.]168. Look for unexplained gaps in firewall traffic logs, especially after a logging daemon crash, and for bursts of segmentation faults in portal processes. Compare against copies held in your SIEM or log server, because the gateway's own logs may have been altered.

Virtualisation layer. Search ESXi and vCenter logs for SSH logins from firewall interface addresses, use of vpxuser outside vCenter's normal management traffic, and files named DREAM_ANNEXATION.txt. Check Point Research publishes SHA-256 hashes for the webshell, TSGA, gogo, destroy_v6 and the note, which your EDR or file-integrity tooling can search for.

If you find signs of compromise

1. Preserve before you change anything. Take a CPInfo and copies of /var/log/dynamicCli.log, portal logs and the files above, and snapshot virtual gateways.

1. Isolate. Close the portal to the internet, or move traffic to a known-clean cluster member, and contact Check Point support or its incident response team.

1. Rebuild rather than clean. TSGA can persist through backups and snapshots, so a restore from a recent backup may bring it back. Rebuild from clean media on the fixed take and restore configuration you have reviewed.

1. Rotate everything the gateway held. Administrator and Expert passwords, VPN and Mobile Access credentials, LDAP or RADIUS service accounts, SIC and VPN certificates, and pre-shared keys. Treat vCenter-managed ESXi credentials, including vpxuser, as exposed and rotate them following Broadcom's VMware guidance.

1. Check the data centre. Confirm ESXi hosts and datastores are intact, make sure backups are offline or immutable, and restrict SSH to ESXi management interfaces so a firewall cannot reach them.

1. Report. UK organisations that find personal data was accessed must assess the risk and, where a risk to people is likely, notify the ICO as soon as possible and where feasible within 72 hours; the ICO also suggests telling the NCSC when a malicious actor caused the breach. US agencies follow the forensic triage steps in CISA's BOD 26-04 guidance. Other US organisations should follow their sector and state rules; CISA also takes reports of indications of compromise.

US and UK: what the KEV date means for you

United States. KEV timelines are compulsory for federal civilian executive branch agencies under BOD 26-04, which CISA issued on 10 June 2026 and which revoked BOD 22-01 and BOD 19-02. The directive does not apply to contractors unless their procurement contract says so, but agencies must review contracts to decide what changes are needed, so federal suppliers running Check Point should expect questions. Our BOD 26-04 explainer covers what that means for SaaS and FedRAMP providers.

The forensic triage flag means agencies must remediate within three days and examine the asset for compromise, not just patch it. Under the directive's timeline table, that three-day clock applies to publicly exposed assets. With CISA's ratings for this CVE (not automatable, total control), an agency asset that is not publicly exposed gets 14 days, which runs to 27 November. CISA's implementation guidance sets out the triage steps: scoping, preserving evidence, patching, containment, analysis and an escalation decision. It is a sensible bar for private companies too.

United Kingdom. KEV is a US list with no legal force in the UK, but it records vulnerabilities CISA has evidence of being exploited, which makes it a useful patching benchmark. If an exposed gateway shows any of the indicators above and personal data passed through it, assess the risk now. The ICO updated its guidance in May 2025 to stress reporting early and updating later, so do not wait for the investigation to finish.

Which gateways come first

Check Point recommends the November Jumbo Hotfix on all management servers and gateways as soon as operationally possible, with internet-facing Mobile Access first. The order below follows that advice and the two SKs.

Why edge gateways keep landing in KEV

Check Point is not alone. Since 13 October, CISA's catalogue has also added exploited flaws in edge and remote-access products from Ivanti, Cisco, SonicWall, Palo Alto Networks and Barracuda. The Check Point case adds two lessons. A flaw in a widely used runtime, PHP, became a firewall flaw because the portal embeds it, which is why our PHP2Shell explainer put vendor appliances on the inventory list beside web servers. And a local-only privilege escalation scored 7.8 still ended in a wiped hypervisor, because the portal flaw had already given the attacker a local foothold.

Three changes reduce the next one. Keep web portals on firewalls closed unless a business case requires them, and put remote access behind identity-aware access where you can. Treat Jumbo Hotfix releases for internet-facing gateways as emergency changes measured in days. And separate the management network so a firewall cannot open SSH sessions to hypervisors, which would have blocked the destructive stage Check Point describes.

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021, assessed at CMMI Level 5 and MSME certified, with senior-led engineering teams working across AWS, Microsoft and Google platforms. Our cybersecurity services team can run the compromise checks in this article across a Check Point estate, review DynamicCLI and portal logs, and plan credential rotation and gateway rebuilds. Talk to us at /contact-us/.

Last updated: 15 November 2026.

References

1. Known Exploited Vulnerabilities Catalog, entry for CVE-2026-123039 — CISA

1. CVE-2026-123039 record, Check Point CNA with CISA ADP enrichment — CVE Program

1. Security Advisory: Active Exploitation of PHP2Shell and Local Privilege Escalation, 12 November 2026 — Check Point Blog

1. sk1000362, CVE-2026-123039 local privilege escalation to root in the DynamicCLI process — Check Point Support

1. sk1000302, Check Point response to CVE-2026-109618, CVE-2026-109619 and CVE-2026-115560 — Check Point Support

1. PHP2Shell Exploitation on Check Point Gateway, 12 November 2026 — Check Point Research

1. Known Exploited Vulnerabilities Catalog, JSON feed version 2026.11.13 — CISA

1. CVE-2026-109618 record, PHP CNA — CVE Program

1. CVE-2026-109619 record, PHP CNA — CVE Program

1. Personal data breach reporting — Information Commissioner's Office

1. BOD 26-04: Implementation Guidance for Prioritizing Security Updates Based on Risk — CISA

1. BOD 26-04: Prioritizing Security Updates Based on Risk, 10 June 2026 — CISA