Check Point patches a login stack overflow that grants unauthenticated root on management servers

September 17, 2026. Check Point ships an emergency fix for CVE-2026-91843, a CVSS 9.8 stack overflow in the login process of its management and log servers. September 9. The vendor had already closed two CVSS 9.8 flaws in its VPN certificate handling. Eight days, then, between two critical alerts aimed at the Check Point ecosystem. Why it matters: this time the target is not the gateway but the management plane — the machine that administers every security policy in the fleet.

Why the management server is the most expensive target

Every firewall vendor draws the same line: on one side, the gateway that carries traffic; on the other, the management server that decides everything else. In Check Point’s architecture the Security Management Server centralises administration, policy deployment, logging and visibility across all of an organisation’s gateways. The Log Server receives and stores security telemetry. Multi-Domain extends the same model to large environments partitioned into domains.

Compromise this layer and the attacker does not steal a flow or a session: they gain control of the filtering rules, the administrator accounts, the network configuration and the security logs. It is the difference between breaking into one room and taking the central guard post — from there you can open doors, erase your tracks and lock the defenders out.

That is what makes CVE-2026-91843 worse than the average product flaw: it fires before authentication, on a service meant for administrators, and it ends in arbitrary code as root.

What the flaw actually does

The vulnerability is a stack overflow in the login routine of the Security Management Server, Multi-Domain Security Management Server, Log Server and Multi-Domain Log Server. According to the vendor, a specially crafted authentication request triggers the overflow before the user even logs in — meaning an attacker with no account at all can drive remote code execution at the highest privilege level on the box.

The exact mechanics have not been published in detail, but the consequence is unambiguous: the management plane falls under the control of an unauthenticated third party. And the vendor itself removed any guesswork from detection: administrators should search SmartConsole Audit and Admin login logs for the message “Administrator failed to log in: Username too long”. That line — an oversized username being refused — is the manufacturer-provided indicator of an exploitation attempt, especially when it originates from an unusual, untrusted or directly internet-facing IP address.

Affected versions, and the ones that are not

The affected surface is broad. The following generations are vulnerable:

• R82.20, all releases before the fix;
• R82.10, up to and including Jumbo Hotfix Take 44;
• R82, up to and including Jumbo Hotfix Take 126;
• R81.20, up to and including Jumbo Hotfix Take 166;
• R81.10, up to and including Jumbo Hotfix Take 190;
• the older R80, R80.10, R80.20, R80.30, R80.40 and R81 branches, now end-of-support.

Two cases are exempt. Smart-1 Cloud environments are not vulnerable, the fix having already been applied to the managed service. And organisations that enabled automatic updates under the vendor’s recommended configuration are protected without lifting a finger — one more argument for leaving that option on for security appliances.

Two CVSS 9.8 flaws in eight days

CVE-2026-91843 does not land in a vacuum. On September 9, 2026, Check Point had already closed CVE-2026-85102 and CVE-2026-85103, two CVSS 9.8 flaws in the validation and decoding of its VPN certificates, exploitable without authentication for remote code execution. The Dutch NCSC judged exploitation imminent at the time.

Eight days later, the scenario repeats against an even more sensitive target. Read together, the two events change the nature of the signal: this is no longer “a vendor patches a flaw” but “a vendor under sustained pressure on its administration and encryption surfaces”. Two unauthenticated root alerts in one week is not bad luck; it is a target profile — and the attackers understood it before the defenders did.

The operational consequence is twofold. First, Check Point’s emergency patch cadence must be folded into the vendor’s continuous monitoring, alongside its products: a subscriber who discovers the alert three days late has already lost. Second, hunting should not wait for the fix: the “Username too long” message in administration logs is an indicator the vendor ships precisely for this, and it is worth searching for before the patch even lands.

# Search administration logs for the exploitation indicator
grep -R "Username too long" "$FWDIR/log/" 2>/dev/null

$FWDIR is the Check Point installation directory, where the management server writes its logs. An occurrence from an unknown IP is a signal to escalate immediately.

Patch, verify, restrict

The fix ships through Check Point’s emergency channel: a LivePatch, not a routine Jumbo Hotfix. The bundles are LivePatch Take 29 for R82.20, and Take 28 for R82.10, R82 and R81.20. Deploy on every management, multi-domain and log server — not just the gateway.

Verification is not done by eye. In Expert mode, cplp list must show the fwm:fwm patch as “armed” with an explicit reference to CVE-2026-91843:

# Expert mode — confirm the LivePatch is armed
cplp list
# Expected output: fwm:fwm  armed  livepatch CVE-2026-91843

If that line is absent, the patch is not active — rerun the install rather than assuming it is fine.

The containment measure is every bit as urgent as the patch. Check Point recommends restricting SmartConsole Trusted Clients to explicitly approved IP addresses or subnets, and above all never leaving the Client Type set to “Any”. A management server has no reason to be reachable from the whole internet; leaving it wide open hands the flaw a direct line of fire.

The timing matters as much as the severity. Management servers are exactly the kind of asset security teams patch last — they are brittle, rarely idle, and a bad patch takes the whole console down. That hesitation is precisely what a root, unauthenticated flaw on the login path exploits. The vendor’s own “Username too long” indicator turns that hesitation into a deadline: if you see it in your logs, you are not deciding whether to patch — you are responding to an incident.

Verdict

CVE-2026-91843 is not an isolated incident but the second CVSS 9.8 Check Point flaw in eight days — after the VPN certificate issues of September 9. The pattern is instructive: a vendor that concentrates administration and logging into a single tier makes that tier a prime target, and a root, unauthenticated flaw on it can erase years of defensive posture in one request. If you run a Check Point management server, apply the LivePatch for your branch now, verify with cplp list, then restrict Trusted Clients to your administration hosts — in that order. If your management servers are reachable from the internet, treat that exposure as potential compromise and hunt the logs for “Username too long” before closing access. If you are on Smart-1 Cloud, you are covered on the patch side, but use the moment to audit who can reach the console: the weakest link is rarely the one you just fixed.

References

• Check Point — SK1000155, “CVE-2026-91843 - Stack overflow in login process to the Security Management and Log Servers”
• The Hacker News — “Critical Check Point Management Flaw Lets Unauthenticated Attackers Run Code as Root” (September 17, 2026)
• Cyber Press — “Critical Check Point Flaw Lets Remote Attackers Gain Root Code Execution Without Login”
• Security Affairs — “Check Point Fixes Critical CVE-2026-91843 Allowing Root Code Execution”
• aicybr — “Check Point CVE-2026-91843: Patch the Management and Log Server Root RCE”