Check Point CVE-2026-91843: Pre-Auth Root on the Firewall Management Server

Check Point disclosed CVE-2026-91843 on 16 September 2026: a stack-based buffer overflow in the login process of the Quantum Security Management Server, Multi-Domain Server and Log Server. An unauthenticated attacker sends a login request with an oversized username, the overflow fires before any credential is checked, and the result is code execution as root. CVSS 9.8. The advisory (sk1000155) shipped the same day, and by 18 September the affected-version list had grown to include R82.20 after Censys confirmed all builds of that branch are vulnerable.

This is not a bug on a gateway. It is a bug on the machine that manages the gateways — the one holding the security policy, the SIC certificate authority, the VPN configuration and the admin credentials for an entire estate. Pre-auth root there is not one compromised host. It is control of the enforcement plane.

What CVE-2026-91843 actually is

The defect is CWE-121, a classic stack-based buffer overflow. The vulnerable code path is the login handler on the management server's administration service. It copies the supplied username into a fixed-size stack buffer without bounding the length. Send a username longer than the buffer and you overwrite the saved return address; craft it precisely and you redirect execution into a payload you control. Because the copy happens before the password is validated, no account, no token, no prior foothold on the appliance is required. Network reachability to the login service is the entire precondition.

Two properties make this worse than a generic RCE:

• It runs as root. The management daemon runs privileged, so there is no second escalation step. The overflow lands you at the top.
• The blast radius is one-to-many. A gateway compromise costs you one enforcement point. A management-server compromise costs you the policy that every gateway pulls, the certificate authority that signs the Secure Internal Communication (SIC) trust between them, and the audit log that is supposed to tell you any of this happened. The attacker does not need to touch a single firewall directly; they push policy to all of them.

Check Point delivered the fix through LivePatch rather than a standalone build. Systems with automatic updates enabled per sk175504 receive it without operator action. The patched Jumbo Hotfix Takes are R82.20 Take 29, R82.10 Take 28, R82 Take 28, and R81.20 Take 28. R81.10, R81 and every R80.x branch are End of Support and get no fix — for those, upgrading is the only remediation.

The reachability question CVSS can't answer

The standard response to a 9.8 is "it says network-exploitable, patch now." That is correct and you should. But the number hides the operational question that actually decides your exposure: is the login service reachable from where an attacker realistically stands?

Check Point's own hardening guidance says the management server should never be internet-facing. In a well-run network it sits on a management VLAN, reachable only from a jump host. So two organisations running the identical vulnerable R82.10 Take 40 build can have completely different real risk — one exposes the administration port to a foothold-able segment, the other does not. CVSS scores neither. It scores the bug in the abstract.

The abstraction is not academic. Censys observed 3,836 hosts globally carrying the Security Management / Log Server role, discoverable with host.services.checkpoint_topology.common_name: "cp_mgmt". That is total product presence, not confirmed-exposed count, but it tells you the population that has to answer the reachability question is large, and that a non-trivial share of it is answering "yes" without meaning to.

"We patched within the window." "Which management servers were reachable from the DMZ before you patched?" "…the ones behind the jump host weren't exposed." "Was the jump host in scope for the last credential-theft test? Because that's the box that reaches the login service."

The gap in that dialogue is the whole point. Reachability is a property of your topology under a realistic foothold, not of the CVE. And it is not a thing you can read off an advisory.

A pattern, not a surprise

Memory-safety bugs in the pre-authentication attack surface of security appliances are now a category, not an anomaly. The last three years produced a steady run of them across the vendors whose boxes sit at the perimeter — Fortinet, Palo Alto, Citrix, Ivanti and now Check Point's management tier. The shape repeats: a C-language service that must parse attacker-controlled input before authentication, a length it forgets to bound, and a device that runs it as root because it was built when "trusted appliance" meant something.

The uncomfortable part is where these live. The industry spent a decade moving application code to memory-safe languages and sandboxed runtimes. The devices we bought to enforce that discipline are frequently the ones still shipping unbounded strcpy-class handlers on a privileged network daemon. The management server is the most sensitive instance of the pattern, because it is the one box whose compromise is transitive to everything downstream of it.

	Gateway RCE	Management-server RCE
Hosts compromised	one enforcement point	the policy plane for all of them
Trust impact	that tunnel	the SIC certificate authority
Evidence	gateway logs	the audit log the attacker now owns
Recovery	reimage one box	rebuild trust across the estate

Remediation

Treat this as a management-plane incident-readiness exercise, not a routine patch. The fix is simple; the exposure and eradication questions are not.

1. Am I affected? Identify every Security Management, Multi-Domain and Log Server and record its version and Jumbo Hotfix Take. Vulnerable if: R82.20 (any build), R82.10 at Take 44 or below, R82 at Take 126 or below, R81.20 at Take 166 or below, or any R81.10 / R81 / R80.x (End of Support). From outside, enumerate exposure with the Censys role query host.services.checkpoint_topology.common_name: "cp_mgmt" against your own ranges — anything that answers is reachable from the internet and is your first priority.

2. Patch — exact fixed versions. Apply the LivePatch. Fixed Takes: R82.20 Take 29, R82.10 Take 28, R82 Take 28, R81.20 Take 28. If automatic updates (sk175504) are enabled the LivePatch installs without action; confirm it landed with cplp list, which should show the BUNDLE_URGENT_SECURITY_UPDATE. End-of-Support branches have no patch — upgrade to a supported branch; there is no compensating control that makes an unpatched EoS management server safe.

3. Can't patch immediately? Compensating controls. Restrict the administration/login service to the management VLAN and a named jump host with an explicit allow-list; deny everything else at the perimeter and at the local interface. If the management server is internet-reachable, that is the emergency to fix first, before the patch — it collapses the attack surface to zero for external actors while you schedule the LivePatch. Do not rely on the login service rejecting bad credentials; the overflow fires before authentication, so credential policy is irrelevant here.

4. Hunt for compromise. The known signature is a Username too long entry in the Check Point audit log — an exploitation attempt against the overflow. Map the post-exploit behaviour to ATT&CK: exploitation of a remote service (T1190) into execution as root, followed by the moves that matter on a management server — tampering with the audit trail (T1070), harvesting the SIC certificate material and admin credentials (T1552), and pushing or altering policy (a legitimate management action performed by an illegitimate operator, which no signature will flag). Because a rooted management server controls its own logs, absence of the Username too long line after a suspected window is not proof of safety — it is one of the first things an attacker with root would remove.

5. Eradicate and verify. If you find evidence of compromise, patching is not eradication. A root-level attacker on the management server may have exported the SIC CA, admin credentials and VPN pre-shared keys — all of which survive a patch. Rebuild the management server from known-good media, re-establish SIC trust with fresh certificates across the estate, rotate administrator credentials and any VPN secrets the box held, and only then confirm clean. Verify after the rebuild that no unexpected policy, administrator account or scheduled task was left behind.

Where Zero Hunt fits

Every question in the section above except "which version am I running" is a reachability and evidence question, and both are exactly where a static CVSS number goes quiet.

Zero Hunt's AI Generative Pentest answers the reachability half directly. Its 10-agent swarm — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, Tactic, Report, coordinated by an AI Controller — does not read your version and infer risk. It takes a realistic foothold and asks whether the crafted long-username login request actually reaches the management server's login service from there, on your build, through your topology. The Exploit agent writes the probe as per-target code from a local LLM — not a public proof-of-concept, which for this CVE does not yet exist — and every skill is backtested in the AI Gym against the Vulhub and CVE-based black-box corpora before it runs in production. A change-triggered campaign fires within the hour when a new management interface appears on the perimeter, so the answer to "is our manager exposed" is continuous, not a quarterly snapshot. Each finding is ECDSA-signed at write time, so "the manager was reachable from the DMZ on 18 September, and here is the proof" is a defensible artifact, not a memory.

Once the box is rooted, the evidence half moves to AI Traffic Analysis. A compromised management server owns its own audit log — the Username too long line, the policy-push record, the shell history — so on-appliance telemetry becomes the attacker's statement, not evidence. The wire does not. Zero Hunt's deep-learning model with four inference heads reads the anomalous login payload, the post-exploit beacon to a never-seen ASN, and the SIC-material exfiltration as they happen, at 2.7+ Gbit/s on the appliance GPU, on a surface the rooted box cannot edit. And because a firewall management server is squarely in NIS2's critical-infrastructure scope, the same finding maps automatically across the 32 compliance frameworks — one exposure, evidenced once, signed once, reportable everywhere it is owed.

Patch CVE-2026-91843 today. Then prove — don't assume — that the box was never reachable from where the attackers actually stand.