CVE-2026-16232, Check Point SmartConsole: authentication bypass to full admin, exploited in the wild (CVSS 9.1)

The prior entry covered the actively-exploited Check Point SmartConsole authentication bypass CVE-2026-16232. NCSC-NL advisory NCSC-2026-0264 (2026-07-24) and CERT-FR CERTFR-2026-AVI-0912 (2026-07-23) now confirm that the same Check Point patch release carried two further CVEs on the same attack surface that had not been surfaced individually (NCSC-NL, 2026-07-24; CERT-FR, 2026-07-23).

CVE-2026-62144 (NCSC-NL CVSS v4 10.0; Check Point publishes only a qualitative "High" severity, no numeric CVSS 3.1 score) lets an unauthenticated network attacker "run any command on the Management including run-script and exec-command on Security Gateway", i.e. arbitrary command execution against a Security Management or Multi-Domain Security Management server, and by extension against every gateway that server manages, whenever the Management is reachable without firewall protection or with an unrestricted Trusted Clients (GUI clients) list (Check Point PSIRT sk185152, 2026-07-22). CVE-2026-62145 (Check Point CNA CVSS 3.1 7.5; NCSC-NL CVSS v4 9.4) is a Gaia Portal escalation in which "an authenticated attacker with read-only access [can] run commands as root," affecting Security Gateways and Security Management alike (Spark Gateways excepted) (Check Point PSIRT sk185153, 2026-07-22). Both span the same version range as the exploited CVE-2026-16232 (R77.30 through R81.20/R82/R82.10 prior to fix) and both close with the same Jumbo Hotfix Accumulator line.

The material delta for defenders is exposure, not new exploitation: Check Point reports only CVE-2026-16232 seen abused, against a small number of customers who left the Management internet-exposed with a permissive Trusted Clients configuration (NCSC-NL, 2026-07-24).

The earlier entry recorded that this Check Point Security Management authentication bypass was being exploited in the wild and had been added to CISA's KEV catalog, but not how it worked. Rapid7 Labs has now published the mechanics, reverse-engineered from decompiled Java across a vulnerable R81.20 Jumbo Hotfix Take 146 build and the patched Take 158 (Rapid7 Labs, 2026-07-28).

The root cause is a trust boundary drawn in the wrong place. A SmartConsole login crosses two generations of management-plane plumbing: the legacy FWM/CPMI service on TCP 18190, which uses Check Point's SIC certificate-based trust mechanism, and the newer CPM/DLE SOAP service on TCP 19009 under the /cpmws/ path (Rapid7 Labs, 2026-07-28). In the vulnerable build, the method that authenticates a remote application preferred whatever SIC distinguished name the caller supplied, falling back to the DN bound to the authenticated peer certificate only when the caller supplied none, so a remote client that simply copied the management server's own SIC DN into that field was accepted as that identity, with no client certificate ever presented (Rapid7 Labs, 2026-07-28).

What turns that identity confusion into full administrative control is a second, separate authorization shortcut. Holding the forged application identity, the attacker issues a gen-sso-token request to the legacy FWM service claiming system_admin with all bits set across the permission mask; Rapid7's decompilation shows FWM allows that command before the normal permission-mask check whenever the client is treated as a Check Point config administrator, which the forged identity guarantees (Rapid7 Labs, 2026-07-28). The resulting SSO ticket is then redeemed through the ordinary SmartConsole login path for a full-administrator session able to modify security policy and configuration (Rapid7 Labs, 2026-07-28). The Take 158 patch narrows the caller-supplied-DN path to loopback CN=siclocal traffic only, binds remote callers to their authenticated peer certificate DN regardless of what they supply, and rejects a mismatch with an explicit logged error (Rapid7 Labs, 2026-07-28).

The operationally consequential sentence is about configuration, not code: Rapid7 states exploitation needs network access to the Management Server plus a Trusted Clients configuration that does not restrict GUI clients, and that this was a default setting in its testing (Rapid7 Labs, 2026-07-28). That sits in direct tension with the vendor's own framing recorded in the original entry, where Check Point describes the flaw as affecting only a very specific configuration. The two positions are not reconcilable from the public record, and the difference decides how much of an estate is in scope: on Rapid7's reading an unpatched management server is exploitable as shipped, on Check Point's it is exploitable only where the configuration departs from the norm. A defender sizing exposure should plan against the former and verify the Trusted Clients setting directly rather than assuming either. Detection, for that retrospective question: the patched build logs a rejection when a supplied DN does not match the authenticated certificate DN, so on patched servers that log line is a direct attempt indicator; on servers that were unpatched during the window, the telemetry to reconstruct from is the management server's own administrator audit trail, a full-administrator session, and any policy or configuration change it made, that cannot be tied to a known administrator authenticating from a known client. Triage: legitimate SmartConsole administrator sessions originate from your operator workstations and correspond to named accounts your directory can vouch for; the discriminator is an administrator-privileged session whose client address falls outside the Trusted Clients set you intended, or a policy change with no corresponding named-operator login.