Check Point CVE-2026-123039: A World-Writable Socket Hands Out Root on Gaia

Check Point CVE-2026-123039 is a local privilege escalation in Gaia OS, and it is being exploited. The Dynamic CLI daemon, dynamic_server, runs as root and listens on /tmp/dynamic_socket. On affected builds that socket is world-writable and the daemon never checks who is connecting, so any process already running on the box can send it a command and have it run as root. Check Point says it has seen the bug exploited against "a couple of dozen customers". CISA added it to the Known Exploited Vulnerabilities (KEV) catalog on 13 November 2026.

If you run Check Point Force Firewalls, Security Management or Log Servers, Multi-Domain Security Management, Multi-Domain Log Servers or a Maestro Orchestrator on R81 through R82.20, do three things today. Install the fixed Jumbo Hotfix Accumulator take from sk1000362. Run the three log checks Check Point published in that article. And confirm that the socket's permissions changed after the patch. The rest of this post explains why a "local" bug on a firewall deserves emergency handling, how to hunt for it on Gaia, how to harden administrator access, and how to keep network appliances patched as a habit. A short section at the end covers the other KEV entry from the same day, UnrealIRCd CVE-2026-114713.

The short version

What the Dynamic CLI is, and what went wrong

Gaia is the Linux-based operating system under Check Point's gateways and management servers. Administrators normally work in Gaia Clish, a restricted command shell, and drop into Expert mode, the root-level Bash shell, only when they need to. Check Point's sk144112 is titled "Dynamic CLI: Enhancing Gaia Clish with new 'Expert' mode commands". The Dynamic CLI is the mechanism that lets Clish offer extra commands which, under the hood, need root to run.

The design is a common one. A small privileged daemon does the root-level work, and the unprivileged front end sends it requests over a local Unix domain socket. That split is reasonable when the daemon checks who is on the other end of the socket. Linux gives a daemon two easy ways to do that: the file permissions on the socket path, and the peer credentials of each connection, which tell the daemon the user ID and process ID of the caller.

According to sk1000362, the affected builds used neither. The root process dynamic_server listens on /tmp/dynamic_socket, the socket is created with mode 0777 so every local user can write to it, and the daemon performs "no authentication of the connecting process". It then executes the command string it receives as root. Check Point's summary is blunt: an attacker who already has local code execution can escalate to root with a single request.

Two details from the advisory tell you what the fix changed.

• Permissions. On a fixed system, ls -l /tmp/dynamic_socket should show srw-rw---- root config (mode 0660) instead of srwxrwxrwx (0777). Only root and members of the config group can write to it.
• Caller checks with logging. The fix "blocks and logs unauthenticated calls". Rejected callers show up in /var/log/dynamicCli.log as Rejected connection from unauthorized uid, with the UID and PID of the caller. Check Point's example shows UID 99, the nobody account, as a sign of an escalation attempt.

The CVE record on NVD describes the same flaw in one sentence: the daemon "runs as root and listens on a world-writable local socket (/tmp/dynamic_socket) without authenticating connecting processes. An authenticated local user can send a command to the socket and have it executed as root." NVD had not finished its own analysis when we checked, so the only score is Check Point's 7.8.

World-writable root sockets are an old class of Linux bug. What makes this one matter is where it lives.

Affected products, versions and fixed takes

Check Point lists four product families as affected in sk1000362:

• Check Point Force Firewalls (Security Gateways)
• Management and Log Servers
• Multi-Domain Security Management and Multi-Domain Log Server
• Maestro Orchestrator

CISA's KEV entry names the same scope in its own terms: "Check Point Firewall, Multi-Domain Security Management Server, Scalable Platforms, Security Gateway, and Security Management Server." Spark Firewalls and Smart-1 Cloud are listed as not affected.

A small discrepancy worth knowing about

The CVE record that Check Point published as the CNA lists the affected ranges slightly differently from the support article. It describes R82.20 with Jumbo Take 10 or below, R82.10 Take 50 or below, R82 Take 130 or below and R81.20 Take 173 or below as affected. The support article says the fix starts at R82.20 Take 14, R82.10 Take 52 and R82 Take 132. For R81.20 the two agree.

That leaves a gap of a few takes on three branches where the two sources do not say the same thing. The safe reading is the support article: install at least the take it names, then check the socket permissions yourself. If your gateway shows srw-rw---- root config on /tmp/dynamic_socket and the daemon logs rejected callers, you have the fix, whatever the take number says.

End-of-support branches

R81.10 and R81 are affected and sk1000362 lists no hotfix for them. If you still run either, the workaround below is the only vendor-documented mitigation, and the real fix is an upgrade to a supported release with a fixed take. Treat any end-of-support gateway that sits on an exposed network path as a priority migration, not a backlog item.

How to check which take you run

Check Point's sk98028 covers this. On R81.x and later, run this in Expert mode:

cpinfo -y all

Look for the Jumbo Hotfix line and its take number. You can also open the Gaia Portal, go to Upgrades (CPUSE), then Status and Actions, and filter to installed packages. From R81.20 Take 38 onward, SmartConsole shows the installed take under Gateways and Servers. In Gaia Clish, show installer packages lists what is installed.

For clusters, sk98028 is explicit that identical takes must be installed on all members. A cluster with one patched member and one unpatched member is still exposed on the unpatched one, and it is also an unsupported cluster.

The workaround, if you cannot patch today

sk1000362 documents a way to stop the daemon and keep it stopped. In Expert mode:

dbset process:dynamic_server f
dbset :save

To confirm it is not running:

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

To turn it back on later, set the value to t and save again. While the daemon is off, the Dynamic CLI commands listed in sk144112 stop working. Record the workaround and remove it once the fixed take is installed.

Technical details

Timeline

The SSVC line is a useful lesson in signal lag. It was written roughly six hours before the KEV catalog update that marked the same CVE as exploited. Automated feeds that read one signal at one moment will sometimes disagree with the vendor and with each other. When the vendor says it has seen exploitation and CISA lists the bug in KEV, those two facts outrank a scoring field that has not caught up.

EPSS shows the same lag. On 13 November it scored this CVE at 0.0127, the 70th percentile, because a bug that needs local access on one vendor's appliance produces little of the broad internet activity EPSS learns from. For a KEV entry the question is already answered. We go into how the three signals interact in our CVSS vs EPSS vs KEV guide.

Where the evidence lives

The daemon logs every command it receives to /var/log/dynamicCli.log. Legitimate requests from Clish arrive with a specific wrapper at the start of the command string. Check Point published three checks to run on every Force Firewall and every cluster member. We reproduce them exactly as given in sk1000362.

Commands that arrive without the expected Clish wrapper:

grep "Received =" /var/log/dynamicCli.log | grep -vF "CPprofile.sh >> /dev/null; export SP_DISTRIBUTE=0; set -o noglob;"

Use of the system() sink, which Check Point says is rare in legitimate traffic:

grep -F "Received = #return_value#" /var/log/dynamicCli.log

Commands commonly seen in exploitation attempts:

grep -EI "Received =.*( id;| whoami| /etc/shadow| ncat| nc -| /dev/tcp| curl | wget | base64| useradd| authorized_keys)" /var/log/dynamicCli.log

After the fix, a fourth check shows attempts that were blocked:

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

Check Point advises that a non-zero or unexpected UID in those lines, such as 99, indicates an escalation attempt, and that you should correlate bursts of them with portal, web and authentication logs to find the source. In practice, that means starting the investigation with whatever low-privilege process on the box an outsider could reach.

What the advisory does not say

sk1000362 says exploitation "requires the attacker to already have local code execution on the appliance". It does not say how the attackers it observed got that foothold, it does not name another CVE as part of a chain, and it gives no dates for the exploitation it saw. Reports that tie this bug to a particular remote flaw or a named threat group should be read as claims until Check Point or CISA says the same. We will update this post if that changes.

Why local privilege escalation on a security appliance matters

A CVSS 7.8 local bug on a laptop is a bad day for one user. On a firewall or a management server it is different, for three reasons.

1. Plenty of things run on the box with low privileges

A Gaia gateway is not a sealed black box. It runs a web portal for administration, VPN services, logging and reporting processes, and administrator accounts that may be restricted to Clish. Each of those is a way for code to end up running on the appliance as some user other than root. The CVSS vector reflects this: it assumes low privileges (PR:L), not administrator access. "Local" here means "anything that has already landed on the device", not "someone at the console".

2. Check Point appliances have a recent history of remote footholds

CVE-2026-123039 is the fifth Check Point vulnerability CISA has added to KEV in 2026. The other four are a good map of the ways attackers have been getting a first foothold on these products this year:

We covered two of those in depth: the IKEv1 VPN bypass and the SmartConsole token bypass. Neither Check Point nor CISA has said that any of them was chained with CVE-2026-123039. The point is structural. Whenever a remote bug, a stolen administrator password or a weak portal account gives an attacker code execution as a non-root user, a bug like this one turns that partial access into full control of the device. Remote footholds and local escalations are two halves of the same attack, and defenders who patch only the "remote" half leave the second half waiting.

Check Point's advisories for the two management server bugs both recommended restricting who can reach management: TCP 19009 limited to trusted addresses for CVE-2026-93616, and SmartConsole Trusted Clients limited to trusted addresses for CVE-2026-16232. That same control shrinks the population of people and processes that can ever reach a local bug.

3. Root on a firewall is root on the trust boundary

Root on a gateway means the attacker can change what the device enforces, read the configuration and certificates it holds for VPN and for its trust relationship with the management server, and watch or redirect traffic that passes through it. Root on a Security Management Server is broader still, because that server pushes policy to every gateway it manages. On a Multi-Domain server it spans every domain on that server.

It also means persistence where few teams look. Appliances rarely carry endpoint tooling and their logs often stay on the box, so a user, SSH key or scheduled task added as root survives until someone checks. The hunting steps below include those checks.

Detection and hunting on Gaia

The steps below assume you have a list of every Gaia device you run. If you do not, building that list is step zero, and the patch hygiene section covers it.

Step 1: Scope your exposure

For each device, record:

• Product type (Force Firewall gateway, cluster member, Security Management Server, Log Server, Multi-Domain server, Multi-Domain Log Server, Maestro Orchestrator, Maestro Security Group)
• Gaia version and Jumbo take (cpinfo -y all)
• Whether its management interfaces (Gaia Portal on TCP 443, SSH on TCP 22) are reachable from anywhere other than a dedicated management network
• Whether it is internet-facing for VPN

Devices on R81 or R81.10, devices below the fixed take, and devices whose portal or SSH is reachable from user or internet networks go to the top of the list.

Step 2: Check the socket

ls -l /tmp/dynamic_socket

srwxrwxrwx means the socket is still world-writable and the device is not fixed. srw-rw---- root config is the post-fix state described by Check Point.

Step 3: Run Check Point's three log checks

Run the three greps from the technical details section on every gateway and cluster member, and on management and log servers too, since they are also affected products. Save the output with the hostname and the time you ran it. An empty result is good news for that log file, but log files rotate, so also check rotated copies if your devices keep them, and note how far back your logs go.

A match does not prove a compromise, but it is a reason to investigate that device right away. Commands like whoami, id, reads of /etc/shadow, curl or wget downloads, base64 blobs or edits to authorized_keys coming through the Dynamic CLI have no business there.

Step 4: Look for the usual persistence

On Gaia, check:

• Users. In Clish, show users lists accounts. Compare against your approved list. For each account, show user <name> shell shows whether it lands in Clish (/etc/cli.sh) or straight in Bash (/bin/bash). Unexpected accounts, or accounts recently switched to Bash, need an explanation.
• SSH keys. Review authorized_keys files for root and every administrator home directory. A key nobody can account for is a strong sign of persistence.
• Scheduled jobs. Review cron entries and Gaia scheduled jobs for anything you did not create.
• Expert mode use. Check who has entered Expert mode recently and when. Check Point's hardening guide suggests alerting on every Expert shell login (more on that below).
• Outbound connections. Unusual connections from the management interface of a gateway, or from a management server to the internet, deserve a look in the logs you already collect upstream.

Step 5: Correlate

Check Point's own advice is to line up rejected Dynamic CLI connections with portal, web and authentication logs. Do the same with the three IOC greps. If a suspicious command in dynamicCli.log follows a portal login from an unfamiliar address by a few seconds, you have found the likely entry point, and that entry point needs its own fix.

Step 6: If you find something

Treat the device as compromised until shown otherwise.

1. Contact Check Point support and follow their incident guidance for your product.
2. Preserve evidence before you change anything: the Dynamic CLI log and its rotated copies, system logs, the user list, and the output of cpinfo.
3. Restrict management access to the device to a single trusted jump host while you work.
4. Rotate every credential the device held or saw: Gaia administrator passwords, Expert mode passwords, SmartConsole administrator accounts that logged in through it, VPN and certificate material per Check Point's guidance, and any shared secrets used for RADIUS, TACACS+ or SNMP.
5. Rebuild from a known-good state where Check Point recommends it. Removing one SSH key does not prove nothing else was left.

Hardening administrator access on Gaia

Patching closes this bug. Hardening shrinks the ways the next one can be reached. Most of what follows comes from Check Point's own Gaia OS hardening guidance and the Gaia administration guide.

Restrict who can reach management at all

Check Point's hardening guide lists the default network services on Gaia as OpenSSH on TCP 22, the Gaia Portal and REST API on TCP 443, and cprid on TCP 18208, and recommends restricting access to those ports to internal trusted networks. Gaia's own allowed clients setting controls which hosts can reach the Gaia Portal and Gaia Clish. The R82 syntax from the Host Access page is:

add allowed-client network ipv4-address <Network IPv4 Address> mask-length <1-31>
add allowed-client host ipv4-address <Host IPv4 Address>
show allowed-client all
delete allowed-client host any-host
save config

An "any host" entry means any remote host can reach the portal and Clish. Add your management subnet first, confirm you can still connect from it, and only then remove the any-host entry, so you do not lock yourself out. On Scalable Platforms, run the commands in gClish for the right Security Group.

For management servers, Check Point's advisories on CVE-2026-16232 and CVE-2026-93616 both recommended limiting SmartConsole Trusted Clients to known addresses and keeping management off the open internet. If your Security Management Server answers on its GUI or API ports from the internet, change that this week whatever your patch level.

Check Point's guide also says Lights Out Management should sit on a dedicated management network, never directly on the internet.

Make Expert mode the exception

Expert mode is the root shell, so the fewer people who can use it, the better. Check Point recommends a Gaia role where the Clish Environment, Expert Mode, Expert Authentication Method, Expert Password and Expert Password Hash features are set to None or Read Only, and assigning that limited role to every administrator who does not need Expert mode. Set those users' shell to Clish:

set user <UserName> shell /etc/cli.sh
save config

The hardening guide also suggests turning on notifications for every Expert shell login through Check Point's cloud automation service, Playblocks. Whatever tool you use, an alert for each root shell login on a firewall is cheap and informative.

Tighten the password policy and add MFA

Check Point's recommended values in the hardening guide are noticeably stricter than the defaults:

The guide also suggests resetting passwords after several upgrades, so that they are re-hashed with SHA-512. Two-factor login for Gaia is documented in sk181854. If you authenticate administrators through RADIUS or TACACS+, make sure the MFA policy applies there too, and that the shared secrets are not the ones that came with your first deployment.

Get logs off the box

A root attacker can edit local logs. Check Point recommends enabling "Send Syslog messages to management server" on gateways (disabled by default) and configuring remote system logging on management servers to an external syslog server. Add the Dynamic CLI log to whatever you collect from these devices, so that the next time you need to run the greps above you can run them on a copy the attacker could not touch.

Network appliance patch hygiene

Network appliances fall through the cracks because they sit with a different team and a failed upgrade takes the network down. These habits keep them from becoming the oldest code in the building. We have written about the wider pattern in VPN and edge appliance zero-days as initial access.

Keep an inventory with versions and takes

For every appliance, record the model, version, hotfix or take level, support status, owner, and which networks reach its management interfaces. When an advisory like sk1000362 lands, the first question is "which of ours are below Take 174", and you want that answer in minutes.

Make KEV a trigger, not a report

When a KEV entry names a vendor in your appliance inventory, open a change within a day. Our running list of recent entries is in CISA KEV additions, 20 October to 13 November 2026, and the October edge device roundup shows how often appliances appear.

Use the vendor's deployment tooling

Check Point's Central Deployment in SmartConsole installs hotfixes and Jumbo takes on gateways and cluster members from the management server, with a Verify step before install, and for clusters it can install on the standby member, fail over, then install on the former active member. Read its limits before you plan around it. The R82.10 guide lists ClusterXL Load Sharing, VRRP clusters, ElasticXL clusters and Security Groups in Maestro or on Scalable Chassis among the unsupported targets, and it cannot run from the Global Domain or Multi-Domain Server context. Those devices need the manual procedure in the Jumbo installation instructions. Maestro customers should note that sk1000362 lists the Maestro Orchestrator itself as affected.

Patch the management plane first

Management servers push policy and hotfixes to gateways, so they are the highest-value target and usually the easiest to patch, since they carry no production traffic. Check Point's R82 Jumbo notes add a practical reason: to upgrade a gateway to R82 Jumbo Take 60 or higher through Central Deployment, the Security Management Server must already run Take 60 or higher.

Verify, then record

After a patch window, check the take on every member, run the socket check, and keep the output. Auditors ask for that record, and it shows later whether a cluster member was skipped.

Retire end-of-support versions on a schedule

R81 and R81.10 get no fix for this CVE, and they will get none for the next one either. Track support end dates and plan upgrades before them.

The other KEV addition on 13 November: UnrealIRCd CVE-2026-114713

CISA added one other entry on the same day. UnrealIRCd is an open source IRC server, and CVE-2026-114713 is in its labeled-response module. According to NVD, UnrealIRCd 6.0.0 before 6.2.7.1 "does not escape the IRCv3 'label' message tag when echoing it into replies, which allows any user on a network with two or more linked servers to inject server-to-server commands that are executed with server authority." The CVSS 3.1 score from MITRE is 8.6. KEV lists the CWE as CWE-140, improper neutralization of delimiters.

The maintainer, Bram Matthys, posted the details to oss-security on 8 November. Because IRC is a text protocol, injecting newlines into server-to-server traffic lets an ordinary user run commands such as KILL and GLINE with server authority. UnrealIRCd 6.2.7.1 shipped on 7 November with fixes for nine issues, and the project offers a hot-patch that applies without a restart on 6.0.0 to 6.2.7 (./unrealircd hot-patch bundle-20261107). UnrealIRCd 5, which reached end of life on 1 July 2023, is also affected, and the maintainer's workaround there is to add blacklist-module "labeled-response"; and restart. The project also published a spamfilter rule as an immediate stopgap for networks where every server runs 6.0.4 or newer.

On exploitation, the project's forum post said, as reported by SecurityOnline, "We are seeing bad guys exploiting this issue on the internet right now." The project described it as the most critical issue found in UnrealIRCd in 15 years and said it found the bug during an internal audit with the help of AI. If your organisation runs IRC for a community, an open source project or internal chat, update or hot-patch now. Networks with a single server are outside the description in the CVE, but the other eight fixes in 6.2.7.1 still matter.

Where Safeguard fits

Safeguard did not discover CVE-2026-123039 or CVE-2026-114713. Check Point and the UnrealIRCd maintainers did the work and published the fixes. The fix for the Check Point bug is Check Point's Jumbo take, installed by your network team. What Safeguard does is help the rest of the security programme respond faster and prove it did.

Vulnerability management that tracks KEV. Safeguard matches components against NVD, GHSA, OSV, CISA KEV and vendor bulletins, and enriches each match with EPSS and KEV status. For the software you build and ship, SCA builds a full transitive inventory and generates SBOMs in SPDX and CycloneDX, so when a library or runtime lands in KEV you can see every project and image that carries it.

Third-party risk for the vendors behind your appliances. Safeguard TPRM lets you onboard a vendor like Check Point, request SBOMs, projects or products from them, score and continuously monitor supplier risk, and see mitigations others have applied. A KEV entry for a vendor is exactly the kind of event that should move that vendor's risk record, and the record is where you note which advisories you acted on and when.

Asset discovery with guardrails. Safeguard discovers repositories, images, packages, SBOMs, vendors and workloads, and applies guardrails and enforcement to what it finds, so "which of ours are affected" has an answer before anyone logs in to systems one by one.

Compliance evidence in one place. Patching a KEV entry is also a control. SOC 2 CC7.1 asks how you identify susceptibility to newly discovered vulnerabilities. ISO/IEC 27001:2022 Annex A control 8.8 covers management of technical vulnerabilities, 8.2 covers privileged access rights, and 8.15 covers logging. GDPR Article 32 asks for security appropriate to the risk. Safeguard's compliance automation maps controls, evidence, tests and vendors across frameworks including SOC 2, ISO 27001 and GDPR, so the patch record, the hardening change and the vendor review land as evidence against the controls they satisfy. Safeguard itself is SOC 2 Type I and Type II audited.

Policies and gates. Safeguard policies and gates apply at build, CI and release. A rule such as "no release ships with a KEV-listed component" turns the KEV feed from a report into an enforced standard for your own software.

DAST and SAST for your own code. Footholds usually start with bug classes like authentication bypass, path traversal or command injection, and those appear in the applications you build too. Safeguard's SAST reviews first-party code, and its DAST runs scoped dynamic tests against targets you have verified you own.

Fix it without waiting for upstream

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Griffin, Safeguard's security model, opens a policy gated pull request that moves the affected dependency to the safe version, and your own CI runs your tests on it before anyone merges. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation categories include dependencies, licenses, security posture and findings, and each one is set separately. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Auto-merge is a separate switch and stays off by default, so your team decides what merges on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds.

3. Gold Registry: start from components that are already fixed

Safeguard Gold rebuilds patched versions of open-source packages and images from source, signs each build, attaches an SBOM, SLSA provenance and VEX, and serves them from registry.safeguard.sh to your organization. Every Gold artifact is held continuously to zero exploitable critical or high CVEs and a completed license check, with signed build provenance (signed with Safeguard's key and verifiable with cosign, SLSA Build Level 3 as the design target) and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened build of a specific package. Ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

For Check Point appliances, today

The block above covers the software you build. For the appliance, here is the order of work, none of which waits on anyone else.

1. Inventory. List every Gaia device with version and Jumbo take (cpinfo -y all), including Maestro Orchestrators and Log Servers.
2. Contain exposure. Limit the Gaia Portal, SSH and SmartConsole to a management network with allowed clients and Trusted Clients.
3. Mitigate where you cannot patch today. Apply the documented workaround and record it with an expiry date.
4. Hunt before you patch. Run the three greps from sk1000362 and keep the output per device.
5. Patch. Management servers first, then gateways and cluster members to identical takes: R82.20 Take 14, R82.10 Take 52, R82 Take 132, R81.20 Take 174 or later.
6. Verify. Check /tmp/dynamic_socket shows srw-rw---- root config, then watch dynamicCli.log for rejected connections.
7. Remove the workaround. Turn dynamic_server back on with t and save once the fix is in.
8. Harden and plan. Limit Expert mode, enable two-factor login, send logs off the box, and book the upgrade for any R81 or R81.10 device.

FAQ

What is CVE-2026-123039?

It is a local privilege escalation to root in Check Point Gaia OS. The Dynamic CLI daemon dynamic_server runs as root and listens on /tmp/dynamic_socket, which on affected builds is world-writable and does not authenticate callers, so any local process can make it run commands as root. Check Point documents it in sk1000362 with a CVSS score of 7.8.

Is CVE-2026-123039 being exploited?

Yes. Check Point says it has observed active exploitation against a couple of dozen customers, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on 13 November 2026. Check Point has not published how attackers obtained the local access the bug needs.

Which Check Point versions are affected, and which takes fix it?

R82.20, R82.10, R82, R81.20, R81.10 and R81 are affected. The fix is in Jumbo Hotfix Accumulator R82.20 Take 14, R82.10 Take 52, R82 Take 132 and R81.20 Take 174, or later takes. R81.10 and R81 are end of support with no fix listed. Spark Firewalls and Smart-1 Cloud are not affected.

The bug needs local access. Why treat it as urgent?

Because on an appliance, local access is what a remote bug or a stolen administrator password already gives an attacker, and this bug turns it into root on a firewall or management server. Check Point has seen it exploited in the wild.

How do I check whether my gateway is patched?

Run cpinfo -y all in Expert mode to see the Jumbo take, then run ls -l /tmp/dynamic_socket. A fixed device shows srw-rw---- root config (0660). If you see srwxrwxrwx, the device is still vulnerable, whatever the take number says.

How do I know if someone exploited it on my device?

Run the three checks Check Point published against /var/log/dynamicCli.log: commands without the normal Clish wrapper, uses of the system() sink, and common attack commands such as whoami, curl, wget, base64 or edits to authorized_keys. Then review users, SSH keys and scheduled jobs. Any match is a reason to open an incident and contact Check Point support.

Did Safeguard find this vulnerability?

No. Check Point disclosed and fixed it, and CISA listed it after confirming exploitation. Safeguard helps after disclosure: tracking KEV and EPSS against your inventory, keeping vendor risk records current, gating your own releases on KEV status, and recording patch evidence against SOC 2 and ISO 27001 controls.

What is the other KEV entry from 13 November?

UnrealIRCd CVE-2026-114713, a label-escaping bug in the labeled-response module of UnrealIRCd 6.0.0 before 6.2.7.1. It lets any user on a network with two or more linked servers inject server-to-server commands. Upgrade to 6.2.7.1 or apply the bundle-20261107 hot-patch.

See how Safeguard would have helped

These demos show the product, not this incident. The appliance patch itself comes from Check Point. Each demo is a flow you would use around it.

The first demo connects Claude to the Safeguard MCP server with OAuth and lets you choose which tools Claude may use. During an incident like this one, your security team can ask in the chat it already uses which vendors and assets are tied to a new KEV entry, and which of your own projects carry KEV-listed components this week. What it can answer depends on what your workspace has scanned and recorded.

Click through it at your own pace, or open it full screen.

The second demo shows the Safeguard CLI fixing a lodash CVE in a repository: it reads the finding and the advisory, asks before any command that changes something, edits package.json, runs the install and the tests, and prints a summary without pushing. The same flow applies when a KEV entry hits a library inside the internal tools your network team uses to manage appliances, such as inventory scripts and automation built on the Gaia REST API.

Click through it at your own pace, or open it full screen.

The third demo is a real Android session. Work is sent to a computer running the CLI, and the command is approved on the phone with Allow once, Allow for turn or Deny. During an out-of-hours response, that is how an engineer away from a desk keeps every change made by the assistant under a human decision.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Check Point sk1000362: CVE-2026-123039 local privilege escalation in the DynamicCLI process, created 8 November 2026, last modified 12 November 2026
• Check Point sk144112: Dynamic CLI, enhancing Gaia Clish with new Expert mode commands
• NVD: CVE-2026-123039, published 12 November 2026
• CISA Known Exploited Vulnerabilities catalog and KEV JSON feed, catalog version 2026.11.13, read 14 November 2026
• FIRST EPSS API, scores dated 13 November 2026
• Check Point sk98028: Jumbo Hotfix Accumulator FAQ
• Check Point Gaia OS hardening guidance
• Check Point R82 Gaia Administration Guide: Host Access
• Check Point R82 Gaia Administration Guide: Managing User Accounts in Gaia Clish
• Check Point R82.10 Security Management Administration Guide: Central Deployment of Hotfixes and Version Upgrades
• Check Point R82 Jumbo Hotfix Accumulator: critical information
• Check Point security advisory, July 2026: active exploitation of CVE-2026-16232
• Check Point sk1000171: CVE-2026-93616
• Check Point sk1000117: CVE-2026-85102
• Check Point: hotfix for vulnerabilities in the deprecated IKEv1 VPN protocol (CVE-2026-50751)
• NVD: CVE-2026-114713
• oss-security: UnrealIRCd 6.2.7.1 and CVE-2026-114713, 8 November 2026
• UnrealIRCd news: 6.2.7.1 release and hot-patch
• UnrealIRCd forum advisory, topic 9487
• SecurityOnline: UnrealIRCd CVE-2026-114713 exploited, 9 November 2026

Last reviewed: 14 November 2026. This is a developing story, so check the linked advisories for the latest status.