If your organization runs Check Point firewalls, there is a good chance that somewhere behind them sits a Security Management Server: the system that pushes out firewall policy, controls administrator access, and collects logs from every gateway it manages. It is not internet-facing in a well-run deployment, but it is one of the most consequential single systems in a Check Point environment. If it is compromised, an attacker does not just gain access to one firewall; they gain the ability to reshape policy across the whole organization.
That is what makes CVE-2026-91843, disclosed this week, worth immediate attention even though there is no evidence yet of active exploitation.
What happened
Check Point notified customers on September 16, 2026, of a critical vulnerability in its Security Management Server and Log Server products. The company rated it 9.8 out of 10 on the CVSS scale, its highest severity tier, and pushed a fix through its LivePatch channel the same day.
The flaw, tracked as CVE-2026-91843, is a stack-based buffer overflow (CWE-121) in the login process, the code that handles a connection attempt before a user has actually authenticated. According to Check Point, it can be exploited by an unauthenticated attacker to remotely execute arbitrary code with root privileges.
As of this writing, Check Point says it has no indication that the vulnerability has been exploited in the wild. Internet scanning firm Censys reported no public proof-of-concept exploit as of September 16, and CISA's assessment attached to the CVE record listed exploitation status as "none" on September 17. The flaw is not currently listed in CISA's Known Exploited Vulnerabilities catalog.
None of that is a reason to wait. Unauthenticated, root-level, network-reachable vulnerabilities in management infrastructure tend to attract attacker interest quickly once technical detail circulates, and Check Point's own recent history (more on that below) suggests these flaws do not stay theoretical for long.
What is CVE-2026-91843?
The vulnerability sits in the login handling code for Check Point's management products. Censys reports that the overflow is triggered by a login request carrying an excessively long username. Because the overflow happens during the login process itself, before credentials are validated, no valid account or prior access is required to reach the vulnerable code.
Check Point told The Hacker News that the vulnerable path runs only through the Trusted Clients setting: the configuration in SmartConsole that controls which hosts are permitted to connect to the management server at all. In other words, an attacker needs network reachability to a host permitted to initiate a management connection; it does not require reachability to just any open port on the internet, provided Trusted Clients is configured correctly.
That caveat matters, and Check Point's own hardening guidance is blunt about it: direct internet exposure of the management interface should be avoided regardless of this vulnerability, and Trusted Clients should never be set to allow any address to connect.
Company vice president Aviv Abramovich confirmed additional detail to The Hacker News after initial disclosure: standalone deployments (where management and gateway functions run on the same system), Log Servers, and Multi-Domain servers are all vulnerable, and R82.20, while not listed in the CVE record itself, is affected as well. Censys separately confirmed that every R82.20 build is affected and that, at the time of its advisory, no Jumbo Hotfix yet protected that branch.
Who discovered CVE-2026-91843 has not been disclosed.
Who is affected?
According to Check Point's CVE record and subsequent vendor confirmation, the following are affected:
| Product / Branch | Affected | Status |
|---|---|---|
| R82.20 | All builds | Confirmed vulnerable (fix via LivePatch) |
| R82.10 | Jumbo Hotfix Take 44 or below | Supported |
| R82 | Jumbo Hotfix Take 126 or below | Supported |
| R81.20 | Jumbo Hotfix Take 166 or below | Supported |
| R81.10 | Jumbo Hotfix Take 190 or below | End of support |
| R81, R80.40, R80.30, R80.20, R80.10, R80 | All | End of support |
Affected product types include Security Management Server, Multi-Domain Security Management Server, Log Server, Multi-Domain Log Server, and standalone deployments. Smart-1 Cloud, Check Point's hosted management offering, is not affected; the fix is already in place there.
A server on any listed branch at the stated Jumbo Hotfix Take or an older one should be treated as vulnerable. Censys reports observing 3,836 internet-visible hosts worldwide presenting the default identity Check Point gives its management and log servers; the firm is careful to note this reflects total role presence, not a confirmed-vulnerable count, since build and hotfix level are not visible from an external scan.
A pattern worth noticing
By The Hacker News' count, CVE-2026-91843 is the fifth critical, unauthenticated, management-reachable flaw Check Point has disclosed since July 22, 2026:
- CVE-2026-16232, a SmartConsole authentication bypass, exploited in the wild in July against customers exposing management directly to the internet without IP restrictions. CISA added it to the KEV catalog the same day it was disclosed.
- CVE-2026-62144, a second management bypass disclosed the same day, not reported as exploited.
- CVE-2026-18574, an authentication bypass allowing command execution on the management server, disclosed August 3.
- CVE-2026-85103, a heap overflow in VPN certificate ASN.1 decoding also reaching Quantum Security Management, disclosed September 9 alongside a related flaw, CVE-2026-85102.
- CVE-2026-91843, this vulnerability.
Check Point says it found the August and September flaws internally and had no indication of exploitation for either. The July authentication bypass, by contrast, was actively exploited before disclosure. Whatever comes of CVE-2026-91843, the pattern is one every organization running Check Point management infrastructure should factor into its patch cadence: this is not a one-off.
What should you do?
1. Confirm whether automatic updates are protecting you
Check Point pushed the fix for CVE-2026-91843 through LivePatch. If your Security Management Server or Log Server has the automatic updates setting (sk175504) enabled, meaning the SmartConsole checkbox under Global Properties and Data Access Control labeled "Automatically download and install Software Blade Contracts, security updates, and other important data" is checked and the Access Control policy has been installed since, the fix should already be applied. Do not assume this occurred; verify it.
Some customers reported delays receiving prior LivePatch packages, with Check Point suggesting a staged rollout rather than a simultaneous push to every customer. Confirm your systems actually received and applied the update rather than treating "automatic updates enabled" as sufficient on its own.
2. Verify the patch is installed
From Expert mode on each management or log server, run:
cplp list
A protected system should show the fwm:fwm patch in "armed" status, in "livepatch" mode, with CVE-2026-91843 referenced in the comment field.
3. Apply the offline package if needed
If automatic updates are not enabled, or you need to patch manually, offline packages are available:
- Take 29 for R82.20
- Take 28 for R82.10, R82, and R81.20
Consult Check Point's advisory, sk1000155, for the full download and installation instructions. The LivePatch must be applied to every affected Security Management, Multi-Domain Security Management, and Log Server; there is no single-point fix that covers a distributed deployment automatically.
4. Get a fix for end-of-support versions
R81.10 and older branches are marked end-of-support in the CVE record, but Check Point has confirmed a fix is available for these versions on request. If you are running one of these branches, log a ticket with Check Point support to obtain it, and treat migration to a supported branch as a priority alongside the immediate fix.
5. Lock down Trusted Clients regardless of patch status
Whether or not you have confirmed the fix is installed, verify that SmartConsole's Trusted Clients setting (under Manage & Settings, Permissions & Administrators, Trusted Clients) restricts management access to specific, known IP addresses or subnets. Check Point explicitly warns against selecting "Any" as the client type. Management access should never be exposed directly to the internet; Check Point's hardening guidance calls for a VPN as a prerequisite for any remote management access.
This is defense in depth, not a substitute for patching, since the vulnerable code path is reached through Trusted Clients connections in the first place. But narrowing who can even attempt a login reduces your exposure window regardless of patch status.
Detection
Check Point has shared one specific indicator: exploitation attempts against this flaw are expected to appear in SmartConsole's Audit and Admin login logs as the message:
Administrator failed to log in: Username too long
If you see this entry, do not treat it alone as proof of successful compromise, but do investigate the surrounding activity: source IP address, timestamp, any subsequent configuration changes, and any unusual management-server processes. Preserve these artifacts for incident-response purposes if the pattern repeats or coincides with other suspicious behavior.
Because the vulnerable code executes before authentication completes, ordinary authenticated-session logging will not capture an exploitation attempt; the failed-login audit trail is the relevant signal here.
Summary
| CVE | CVE-2026-91843 |
| Type | Stack-based buffer overflow (CWE-121) in the login process |
| CVSS Score | 9.8 (Critical, v3.1) |
| Affected products | Security Management Server, Multi-Domain Security Management Server, Log Server, Multi-Domain Log Server, standalone deployments |
| Affected versions | R82.20 (all builds); R82.10 Take 44 or below; R82 Take 126 or below; R81.20 Take 166 or below; R81.10 Take 190 or below and older (end of support) |
| Not affected | Smart-1 Cloud |
| Attack vector | Network, via the Trusted Clients management path; no authentication or user interaction required |
| Trigger | Login request with an excessively long username |
| Public PoC? | None reported as of September 16, 2026 |
| Active exploitation? | None confirmed as of September 17, 2026 |
| Fix | Check Point LivePatch; offline Take 29 (R82.20) or Take 28 (R82.10/R82/R81.20) |
| Interim mitigation | Restrict Trusted Clients to known IPs/subnets; never set to "Any"; do not expose management to the internet |
| Detection signal | "Administrator failed to log in: Username too long" in Audit and Admin login logs |
If you need help verifying LivePatch deployment across your Check Point management infrastructure, auditing your Trusted Clients configuration, or reviewing your broader exposure across the string of Check Point management flaws disclosed since July, get in touch. A root-level, unauthenticated flaw in the system that controls your firewall policy is exactly the kind of thing that deserves attention before, not after, a public proof-of-concept appears.