Check Point Gaia DynamicCLI bug lets a local user run commands as root; CISA adds it to KEV

CVE-2026-123039 covers a world-writable local socket on Check Point gateways and management servers. CISA added it to its known exploited vulnerabilities list on 13 November 2026, with a remediation due date of 16 November.

On this page

What happened

CISA added CVE-2026-123039 to its Known Exploited Vulnerabilities catalog on 13 November 2026, with a remediation due date of 16 November 2026. The entry covers Check Point Firewall, Multi-Domain Security Management Server, Scalable Platforms, Security Gateway and Security Management Server.

The flaw is a local privilege escalation in Gaia OS. The DynamicCLI daemon runs as root and listens on a world-writable local socket at /tmp/dynamic_socket. It doesn't authenticate the processes that connect to it. Any authenticated local user who can write to that socket can send a command and have it run as root.

Check Point's own scoring puts it at CVSS 3.1 base 7.8, high severity, with the vector AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. That vector is worth reading closely: local attack vector, low complexity, low privileges required, no user interaction, and high impact on confidentiality, integrity and availability. The CNA lists CWE-732 (incorrect permission assignment for a critical resource) and CWE-862 (missing authorization).

Affected versions, per the CNA data, are R81.20 with Jumbo Hotfix Take 173 or below, R82 with Jumbo Hotfix Take 130 or below, R82.10 with Jumbo Hotfix Take 50 or below, and R82.20 with Jumbo Hotfix Take 10 or below, for both Quantum Security Gateway and Quantum Security Management. The retained record doesn't state which hotfix takes fix it, and it doesn't say whether a patch exists. Treat the version list as the boundary of what's affected, not as a fix announcement.

How the bug works, and why it matters

The mechanism is short. A daemon with root privileges accepts commands over a socket that any local user can open, and it doesn't check who's on the other end. The permission problem and the missing authorization check compound each other: the socket is reachable, and the daemon trusts whoever reaches it.

The impact is a full step from a low-privileged local account to root on the box. On a security gateway that's the device enforcing policy between network segments. On a management server it's the system holding policy, logs and credentials for the estate. Root there is a bad place to be.

What the KEV listing adds is the claim that this has been exploited in the wild. CISA's catalog entry doesn't say how, against whom, or how many devices. The ransomware field on the entry reads "unknown". So the exploitation is asserted by the listing, and the details behind it aren't in the retained record.

The required action in the KEV entry is to apply mitigations per vendor instructions, following BOD 26-04, and to follow the forensics triage guidance. It also tells agencies to evaluate each asset's internet exposure. That last line matters less here than it usually does: this is a local bug, so the exposure question is about who already has a login on the device, not who can reach it from outside.

HackZoneLabs assessment

In our view the severity score undersells the operational problem, and the KEV listing is the reason. A 7.8 local privilege escalation is routine on paper. One that CISA says is being exploited, on appliances that sit at the edge of a network and hold the keys to it, is a different proposition. We'd treat any Check Point gateway or management server with local accounts beyond the small set of administrators as a priority, and we'd want to know who those accounts belong to before we start patching.

We'd also read the three-day window between the KEV date and the due date as a signal about urgency rather than a comment on difficulty. Nobody has published a write-up in the retained material, so we can't say how hard the step from local user to root actually is in practice. The CVSS vector says low complexity; that's the vendor's assessment, not a demonstration.

What remains unknown

The retained record doesn't say how many devices or organisations are affected, who is exploiting it, or what the exploitation looks like. It doesn't name a fixed version or a hotfix take that closes the hole, and the patch status is annotated as unknown. Check Point's advisory is the place to check for the fix, and the KEV entry points there.

For defenders, the supported priorities are narrow. Inventory Check Point gateways and management servers against the listed version and hotfix takes. Check the vendor advisory for the fix rather than inferring one from the affected range. Review local accounts on those systems, since the bug needs an authenticated local user to start. And if the KEV listing is right that this has been used, look at whether anything on those boxes changed recently that a local account shouldn't have been able to change.

CVE references

CVE-2026-123039

Sources

  1. CVE-2026-123039: Check Point Multiple Products Incorrect Permission Assignment for Critical Resource VulnerabilityPrimarynvd.nist.gov

If something here is wrong, tell us. Every correction is listed on the corrections page.

Don’t Just Read About Cyberattacks. Learn How They Work.

Go beyond the headlines. Explore hands-on cybersecurity labs, understand real-world vulnerabilities, and build practical security skills with HackZoneLabs.

Start Learning