Unauthenticated root on a Check Point management server, triggered by an over-long username at login

Eleven affected versions, four download links

Check Point published advisory sk1000155 on 16 September 2026. Count what is on the page.

The affected list names eleven version bands: R82.20, R82.10 at Jumbo Hotfix Take 44 or lower, R82 at Take 126 or lower, R81.20 at Take 166 or lower, R81.10 at Take 190 or lower, and then R81, R80.40, R80.30, R80.20, R80.10 and R80. The download table underneath offers four packages, one each for R82.20, R82.10, R82 and R81.20.

Four and eleven. The four with a package are exactly the four supported branches. The seven without one are exactly the seven the advisory marks end of support.

That arithmetic does not establish that seven branches are unfixed. Aviv Abramovich, Check Point's vice president of product management for network security, told The Hacker News that a fix for the out-of-support versions exists and that customers who need it should raise a ticket with Check Point support. That route is not on the advisory page.

Censys, reading the same page, reached the opposite conclusion in its rapid response advisory: that those branches get no fix at all and that upgrading to a supported branch is the only remediation. One advisory, two careful readers, two different answers for the same estate. If you run R81.10 or older, the answer you act on comes from a support ticket, not from the page.

Affected branches and the package offered on the page, counted from Check Point advisory sk1000155 on 18 September 2026

Branch	Affected at	Package on the advisory page
R82.20	All builds	Yes, urgent security update take 29
R82.10	Jumbo Hotfix Take 44 or lower	Yes, take 28
R82	Jumbo Hotfix Take 126 or lower	Yes, take 28
R81.20	Jumbo Hotfix Take 166 or lower	Yes, take 28
R81.10, end of support	Jumbo Hotfix Take 190 or lower	No
R81, R80.40, R80.30, end of support	All builds	No
R80.20, R80.10, R80, end of support	All builds	No

What the flaw is, and where in the sequence it runs

The record is short and unusually plain. In Check Point's own words as the CVE Numbering Authority: "A stack overflow during the unauthenticated login process may allow an attacker to run arbitrary code remotely with root privileges." The weakness is classified CWE-121, a stack-based buffer overflow. Censys describes the trigger as a login request carrying an excessively long username.

Three things follow from that sentence, and they are the whole story.

First, the code runs before authentication. Credentials, certificates, lockout policy, password length and multi-factor authentication are all downstream of the point where the overflow happens, so none of them are in the path. Second, the outcome named in the record is root, not an administrator session. Third, the affected products are the management estate: Security Management Server, Multi-Domain Security Management Server, Log Server and Multi-Domain Log Server. Smart-1 Cloud, Check Point's hosted management service, is stated as not affected because the fix was already in place there.

The advisory's verification step names the patched process: cplp list should show fwm:fwm as armed against CVE-2026-91843. That is the management process itself, the one that answers SmartConsole. The patch and the vulnerable code live in the same place, which is why the verification is worth running rather than assuming.

[Expert@MGMT]# cplp list
ID(PATCH:PROC)        STATUS  MODE            COMMENT
--------------------------------------------------------------------------
fwm:fwm               armed  livepatch     CVE-2026-91843

What root on a management server actually reaches

Check Point's Gateway and Management Hardening Administration Guide, revised on 4 September 2026, puts the scope in one sentence: the Management Server controls policy installation, trust relationships and administrator access. Each of those three is worth unpacking, because together they explain why a management server is not simply another Linux host with a high CVSS score.

Policy. The server installs the rule base on every Security Gateway it manages. Root on the server is upstream of the firewall rules on every gateway downstream of it.

Trust. Each Check Point management server runs an Internal Certificate Authority. The Secure Internal Communication documentation is explicit that the ICA signs the certificate for each managed object, and that this trust is what allows policy to be installed on gateways and logs to be sent back. The private material that underwrites fleet trust sits on the machine the flaw reaches.

Administrators. Accounts, permissions, and the Trusted Clients list itself are objects held by that server. An attacker with root can edit the allow-list that was supposed to constrain them.

There is a fourth item the vendor does not need to state, because it follows from the product names: the Log Server is in scope. The logs that would show what an attacker did on the management estate are collected by a machine in the same affected set. Evidence and target share an address.

Is this last week's Check Point flaw? No, and the difference matters

This site covered CVE-2026-85102 and CVE-2026-85103 on 13 September. Those were published on 9 September, seven days before this one, and the confusion is easy to make because all three carry a 9.8 from the same vendor and all three end in unauthenticated code execution.

They are separate flaws. Different weakness class, different code path, different advisory, different affected product list. The honest link between them is narrower than the headlines suggest: CVE-2026-85103 also reaches Quantum Security Management, so a management server could have needed both fixes inside a week. Patching last week's pair does nothing for this one.

CVE-2026-85103 against CVE-2026-91843, from the two CVE records and the two Check Point advisories

Comparison	CVE-2026-85103, 9 September	CVE-2026-91843, 16 September
Weakness	Heap overflow in VPN certificate ASN.1 decoding	Stack overflow in the login process, CWE-121
Products named	Quantum Security Gateway and Quantum Security Management	Security Management, Multi-Domain Security Management, Log Server, Multi-Domain Log Server
Advisory	sk1000118	sk1000155
Vendor statement on conditions	Management vulnerable even when VPN is not in use or configured	Record states no precondition; vendor told a reporter the path runs through Trusted Clients

Five critical pre-authentication management flaws in 56 days

Take the publication dates from the CVE records themselves and do the subtraction. The first of this run, CVE-2026-16232, was published on 22 July 2026. CVE-2026-91843 was published on 16 September 2026. That is 56 days. In between sit CVE-2026-62144 on the same July day, CVE-2026-18574 on 3 August and CVE-2026-85103 on 9 September. The gaps are 0, 12, 37 and 7 days, which sum to 56.

Five critical records in eight weeks, every one of them reachable on a Check Point management server without logging in. The pace is not even. Three of the five records fell inside the first 12 days, then nothing for 37 days, then two more inside a week of each other at the end.

One of the five has been exploited. CISA added CVE-2026-16232 to its Known Exploited Vulnerabilities catalogue on 22 July 2026, the day it was published, with a remediation due date of 25 July, three days later, and it is flagged for forensic triage under Binding Operational Directive 26-04. Check Point's own record for that one says the company was aware of exploitation affecting "a very small number of customers", and that remote exploitation required internet access to the management server and a configuration that did not restrict Trusted Clients.

The cluster is not evidence that this flaw will be exploited. It is evidence about how quickly a defender has had to act on this particular product family, and about what a patch cycle of one urgent management fix every fortnight does to change control. Check Point Software Technologies sells the product and also publishes the advisories, the CVE records and the hardening guide used throughout this piece. That is normal for a CNA, and the records here are unusually specific, but it is worth naming: almost every fact available about this flaw comes from the vendor.

Trusted Clients is an address list, not a control

The advisory's only mitigation, other than the patch, is to limit Trusted Clients to trusted IP addresses and subnets and to avoid using "Any" as a client type. Check Point told The Hacker News that the vulnerable path runs "only through trusted clients".

Read the name carefully, because it is doing a lot of work. Trusted Clients is a source address allow-list held by the management server, configured under Manage and Settings, Permissions and Administrators. It answers one question: is this connection coming from an address we listed? It does not answer who is connecting, or whether the machine at that address is still under its owner's control.

So take the mitigation at its word and follow the consequence. If the vulnerable parser sits behind the address check and in front of authentication, then anything that can source traffic from a listed address reaches it. That list, in a well-run estate, contains the admin jump host, the security team's subnet, and the management network the gateways live on. Those are exactly the machines an attacker aims for first. A compromised workstation inside an allow-list is not stopped by the allow-list.

There is a second word worth the same scrutiny. Check Point says customers with automatic updates enabled are already protected. In the vendor's own documentation, "automatic updates" means the Download Security consent flag, which is the SmartConsole checkbox under Global Properties and Data Access Control labelled "Automatically download and install Software Blade Contracts, security updates, and other important data (highly recommended)". The flag is enabled by default, which is genuinely good news for most estates. But sk175504 also says the configured values take effect through an Install Database or Install Policy operation, and the hardening guide's instructions end with "Install the Access Control policy".

A setting that requires a policy installation to take effect is a setting that can be true in the console and false on the box. That is why the verification command matters more than the checkbox. When Check Point pushed the fixes for last week's VPN pair, several customers reported in its community that the automatic package had not reached them on the day of the announcement. Availability is not coverage, which was the argument in our 13 September briefing and is unchanged here.

Why the UK alert says Medium, and why that is not a downgrade

NHS England Digital issued cyber alert CC-4854 for this flaw on 17 September 2026 at 14:27. Its threat severity is Medium.

A security lead who reads only that word will conclude the NHS considers a 9.8 pre-authentication root flaw a moderate problem. That is not what the label means. Of the 3,055 alerts in the NHS England Digital cyber alerts index, 111 carry High, around one in twenty-seven. On the same day CC-4854 was published, the alert for an actively exploited authentication bypass in Cisco Identity Services Engine and the alert for an exploited flaw in Cisco Secure Firewall Management Center were also rated Medium.

Medium is the house default for a vulnerability alert in that catalogue, not an assessment of your estate. The alert content is useful and it reproduces the vendor's affected version list faithfully. The severity word is the least informative thing on the page. This is the same failure mode as Trusted Clients: a comforting label is not a control, and a severity band is not a risk assessment.

Stated and not stated

The advisory is clear about the fix and nearly silent about everything a responder would want. Here is the split, taken from the sources rather than from the coverage.

What the record establishes and what it leaves open, from Check Point advisory sk1000155, the CVE record, the CISA KEV catalogue and reported vendor statements, on 18 September 2026

Question	On the record	Not stated
Exploitation	Check Point told reporters it has no reports of exploitation. CISA's ADP recorded exploitation as none on 17 September. Absent from the KEV catalogue, version 2026.09.18.	The advisory page itself says nothing about exploitation, in either direction.
Indicators	One audit log string: "Administrator failed to log in: Username too long", in the Audit and Admin login logs.	No addresses, no hashes, no network signature, and nothing about what a successful attempt leaves behind rather than a failed one.
Victims	No count claimed by anyone.	No number, no sectors, no geography, no dwell time.
Who found it	Not disclosed. Check Point did not answer the question when asked.	At least one outlet has credited Censys, a claim Censys's own advisory does not make.
R82.20	Listed as affected by the advisory and by Censys, and confirmed to The Hacker News by Check Point.	Absent from the affected list in the CVE record held by NVD, which names ten bands, not eleven.
Standalone deployments	Check Point confirmed to The Hacker News that standalone deployments are affected.	The advisory does not use the word standalone anywhere.
Out-of-support branches	Check Point says a fix is available through a support ticket.	No package, no take number and no mention of that route on the advisory page.
Severity of the score	9.8 under CVSS 3.1, assigned by Check Point as the CNA.	NVD had not published its own analysis as of 18 September; the record status was still Received. Every 9.8 you have read is the vendor's own number.

What the patch does not undo

LivePatch arms the running process. It does not tell you whether anyone reached that process first. The affected list runs back to R80, so the vulnerable code is old, which is an inference from that list rather than a statement by Check Point about when the defect was introduced. Neither the advisory nor the CVE record says how long it has been there.

Check Point's own recovery guidance, in the Appliance Recovery section of the hardening guide, is the honest description of what "suspected compromise" costs. Preserve evidence first, because reinstallation overwrites it. Reinstall Gaia with the ISOmorphic tool from trusted media. Restore configuration only from backups that predate the suspected compromise. Treat the Lights Out Management card as a separate environment, because reinstalling Gaia does not touch its firmware. Rotate potentially affected credentials, certificates, keys and tokens. And then the sentence that should be quoted in every board paper about appliance security: this guidance "does not guarantee that every compromise will be detected or eliminated".

For a management server, "rotate certificates" is not a line item. It means the Internal Certificate Authority that signs the trust every managed gateway relies on. That is a fleet-wide operation with an outage profile, planned over weeks, not slotted into a patch window. Which is the practical reason to answer the detection question now, while the audit logs still reach back far enough to be worth reading.

Do this, in this order

The question that exposes the gap

Every organisation reading this can answer, by tonight, whether its management servers are patched. That is the easy question, and the advisory hands you the command.

Here is the harder one. Since 22 July, five critical flaws have been published that reach a Check Point management server without credentials, and one of them was being exploited on the day it appeared. If someone had taken root on one of your management servers during those 56 days, what evidence would you be looking at today, held somewhere other than on that server, that would tell you?

For most estates the honest answer is a log file collected by a machine in the same affected product list. That is the gap. Patching closes this week's flaw. It does not close that.

Key facts