Check Point SmartConsole auth bypass: patch, then go hunting
The Check Point management server login that took the caller's word for who they were. Patch the Jumbo Hotfix, lock down Trusted Clients, and check whether someone got in before you.
01 The Big PictureFor leadership · no jargon
Okay, so this one's a bit grim. Check Point's management server, the single box that configures and polices every firewall in the estate, had a login process that took the caller's word for who they were. No password, no certificate, no stolen credentials. An attacker on the network could simply announce "hello, I'm the management server itself" and be believed.
Think of it like a staff badge office where the clerk asks your name, then issues whatever badge matches the name you gave. Give the boss's name, get the boss's badge. The clerk never looks at your face, and the badge in this case is a full administrator session on the thing that controls the entire network perimeter.
This was not theoretical. Check Point confirmed a small number of customers were compromised before the fix shipped, CISA added it to the Known Exploited Vulnerabilities catalogue the day the advisory landed with a three-day deadline, and Rapid7 published working exploit code a week later. The fix is a Jumbo Hotfix that takes minutes to schedule, and the job after that is proving nobody used the door while it was open.
02 Technical BreakdownFor engineers
The SmartConsole login process spans two services on the management server: the legacy FWM/CPMI service on TCP 18190, which speaks SIC (Check Point's certificate-based internal trust protocol), and the newer CPM/DLE SOAP web services over HTTPS on TCP 19009. The root cause sits in the CPM login code, com.checkpoint.management.dleserver.coresvc.internal.LoginSvcImpl, specifically the authenticateRemoteApplication() path.
The tl;dr is that during :certificate_bind, the server trusted the client-supplied :DN field instead of binding the application identity to the authenticated SIC peer. From Rapid7's analysis of the decompiled dleserver.jar:
String effectiveSicDn = suppliedSicDn == null
? this.j.getCertificateDnName()
: suppliedSicDn; // attacker-supplied DN wins LoginSvcImpl in dleserver.jar, decompiled, via Rapid7's root-cause analysis. If the client supplies a DN, the real certificate-derived identity is never consulted.
So the whole dance looks like this, and the cheeky part is that none of it needs a single credential:
- Connect to TCP 18190 unauthenticated and say hello as
CN=Gui_Client. The server happily reads out its *own* SIC DN (something likecn=cp_mgmt,o=gw-5622ca..5otbwa) during the bootstrap. - Replay that DN in a forged
:certificate_bindclaiming to be the "CPM Server" application. No client certificate presented, the bind is pure text. Vulnerable server replies:status (ok). - Grab a DLE application token from an
open-databasereply. - Ask FWM to mint a SmartConsole SSO ticket for
system_adminwith full permissions (ffffffff|ffffffff|ffffffff). FWM'sfwm_is_authorized()has a special case allowinggen-sso-tokenfor cpconfig-admin clients before the normal permission check. Neat for the attacker, that is. - Redeem the ticket over SOAP (
LoginSvcRemoteloginNewwithUserSSOTokenAuthenticationInfo) and walk off with a full SmartConsole admin session.
Rapid7's PoC does all of this in a single stdlib-only Python script, Huffman-codebook FwSet serialiser and all, which is honestly a lovely bit of work (the exploit, not the bug). The patch, diffed by Rapid7 between R81.20 JHF Take 146 and Take 158, only honours a supplied DN for loopback CN=siclocal traffic; remote clients must use the certificate-derived DN, mismatches are rejected, and an empty authenticated identity is rejected outright.
03 Affected
Per Check Point's advisory (sk185169): Quantum Security Management Server and Multi-Domain Security Management Server, versions R77.30, R80, R80.10, R80.20, R80.30, R81, R81.10, R81.20, R82 and R82.10. Everything below R81.20 is end of support, so no fix is coming there; those boxes need upgrading or isolating, full stop.
Fixed in Jumbo Hotfixes released 22 July 2026:
- R82.10: Take 36 or later
- R82: Take 118 or later
- R81.20: Take 158 or later
- Smart-1 Cloud: already protected, per the vendor
Preconditions are annoyingly light: network reachability to the management server, and a Trusted Clients configuration that doesn't restrict GUI clients. Rapid7 found "no restriction" to be a common default, so assume you're open until proven otherwise. The same advisory also covers CVE-2026-62144 (another management auth bypass, not known exploited) and CVE-2026-62145 (GaiaOS WebUI local privesc), so the hotfix is pulling double duty.
04 Detection
Before we change anything, let's see what we're dealing with. First, which JHF take are you actually running? From Gaia clish:
show installer packages installedAnything below Take 36 (R82.10), Take 118 (R82) or Take 158 (R81.20) is live exposure.
Next, hunt for the fingerprint exploitation leaves behind. When the forged ticket gets redeemed, the audit log records it with a distinctive authentication method:
In SmartConsole, open Logs & Monitor > Audit Logs and search for "Authentication method: application token". Any hit you cannot explain as legitimate tooling is a compromised session.
Check Point also published the attacker IPs observed in the wild; sweep your logs for these talking to TCP 18190 or 19009:
151.241.99.207 151.241.99.233 158.62.198.182 192.142.10.99 139.28.37.250Rapid7 adds 194.213.18.137 to the list. Any of these near your management server means incident response, not patching-as-usual.
And if you want ground truth on exploitability, Rapid7's PoC is the cleanest check we have (against your own systems only, obviously):
python3 CVE-2026-16232.py --target <management-ip> Vulnerable target: the bind succeeds and the script walks all the way to a redeemed admin ticket. Patched target: Application bind failed. The target is likely patched and not vulnerable.
05 Remediation
01 Install the Jumbo Hotfix
This is the only step that actually closes the hole; everything below is damage limitation. Deploy Take 36+ (R82.10), Take 118+ (R82) or Take 158+ (R81.20) via CPUSE (Gaia portal > Upgrades (CPUSE)), on an emergency-change basis. The CISA KEV deadline of 25 July has already passed, so "emergency" here means now, not next patch window. On anything below R81.20, there is no hotfix; the only remediation is upgrading to a supported train or taking the management interfaces off the network.
The full package list and download links live in sk185169. Snapshot the management server first, as with any JHF.
02 Restrict Trusted Clients
Even patched, the management plane should not be chatting to the whole network. In SmartConsole: Manage & Settings > Permissions & Administrators > Trusted Clients, and replace "Any" with the named machines or subnets your admins actually work from.
Rapid7 flagged "no restriction" as the common default, and it's exactly the precondition this exploit leans on. An attacker who can't reach the login process can't replay anything at it.
03 Firewall the management interfaces
TCP 18190 and 19009 should only be reachable from your admin subnets and the managed gateways that need them. Review the implied rules for control connections and make sure they're not punching the management ports open further than your policy intends.
The management server accepting logins from the internet is how those "small number of customers" got compromised. Don't be the next anecdote.
04 Hunt before you trust
Rapid7's advice, and it's correct: patching does not evict anyone, and the absence of those published attacker IPs does not prove you were unaffected. If the server was reachable from untrusted networks before the hotfix, treat the audit-log search and IP sweep above as mandatory, and assume credentials minted through the management plane (admin passwords, SIC certificates) may need rotating if you find hits.
Two things worth adding to the hunt, both flagged in community analysis of the intrusion reports. Review admin, policy *and object* changes, not just logins: an attacker can change what a rule does by editing the objects inside it, without the rule name ever changing. And make sure your logs live somewhere the management server can't touch, a SIEM or remote syslog, because a resident attacker with admin rights can degrade local logging to cover their tracks. One caveat on scope: Check Point's advisory says "internet access", but Rapid7's wording is the correct one, plain *network* access is enough. An intruder already inside your flat network qualifies.
06 Verification
Patched and locked down? Let's prove it rather than assume it.
show installer packages installedExpect Take 36+ (R82.10), Take 118+ (R82) or Take 158+ (R81.20) in the installed list.
python3 CVE-2026-16232.py --target <management-ip> The one verification that actually simulates the attack: you want [-] Application bind failed. The target is likely patched and not vulnerable. Credit where due, Rapid7 shipped a checker and an exploit in the same file.
Then re-open SmartConsole and confirm Trusted Clients lists only your real admin hosts, and that the policy no longer lets the wider network reach 18190/19009.
07 Rollback
Rolling back a Jumbo Hotfix is done through CPUSE the same way it went in, but honestly: don't, unless the hotfix genuinely broke something. It reopens an actively exploited 9.3. If the hotfix causes trouble, fix forward, and in the meantime the Trusted Clients restriction plus management-plane firewalling buys you real (if imperfect) cover, since an attacker who can't reach the login process can't exploit it.
If you've already rolled back for operational reasons, treat the box as unpatched from that moment: re-apply the network restrictions, redo the hunt, and get the hotfix back on the schedule.
08 References
- Check Point advisory sk185169
- Check Point blog: action required, active exploitation (22 July 2026)
- Rapid7 PoC: github.com/sfewer-r7/CVE-2026-16232
- Rapid7 root-cause analysis (28 July 2026)
- Rapid7 ETR: exploited in the wild (23 July 2026)
- NVD: CVE-2026-16232
- CISA Known Exploited Vulnerabilities catalogue
If I've got anything wrong here, or you've hit an edge case I haven't covered, do say: corrections and questions are always welcome :)
Ship the fix. Prove it’s closed.
If this runbook doesn’t fit your stack, send the CVE — an operator writes a verified path, usually within a business day. Or contribute your own and get co-authored credit.