Check Point has confirmed active attacks on a critical SmartConsole authentication bypass. The flaw sits in its Security Management and Multi-Domain Management servers. A working proof-of-concept is now public too. The bug is tracked as CVE-2026-16232 and carries a CVSS score of 9.3. It lets an unauthenticated attacker walk away with full administrator access to the management plane.
Rapid7 published a technical breakdown of the bug on 22 July. That was the same day Check Point shipped emergency Jumbo Hotfixes. Days later, Rapid7 researcher sfewer-r7 released a Python proof-of-concept on GitHub. It checks whether a given target is patched. A confirmed in-the-wild attack plus a public exploit script is exactly the pattern defenders dread.
How the SmartConsole authentication bypass works
The bug sits in how SmartConsole’s login process handles Secure Internal Communication (SIC) identities. A properly configured server should bind an application’s identity to the certificate it authenticated with. This one does not. It accepts an attacker-supplied SIC distinguished name instead, without checking it against the peer certificate actually presented.
That gap opens a short exploit chain. An attacker on the network reads the management server’s own SIC DN during an unauthenticated bootstrap exchange. They replay that DN inside a forged application certificate bind. The server hands back an application login token. From there, the legacy management service can be tricked into minting a fresh SmartConsole single sign-on ticket. The attacker is in, with administrator rights, free to rewrite firewall policy.
Exploitation needs network reach to the management server’s IP address. Check Point’s own advisory narrows the real-world risk further. It applies when Trusted Clients, the setting that restricts which GUI clients can reach the console, is left open rather than locked to specific addresses. Rapid7 Labs reproduced the attack against R81.20 and R82.10 builds in testing. Check Point’s advisory lists R81.10, R82 and older branches as affected too.
Confirmed exploitation, not just a theoretical bug
Lotem Finkelstein, Check Point’s VP of Research, wrote in the vendor’s advisory that “following a thorough analysis, we identified one of those in the wild, affecting a handful of customers.” He added that the exposure is narrow: “this only affects a very specific configuration, when Management is exposed directly to the internet without IP restrictions.”
Small blast radius or not, the US Cybersecurity and Infrastructure Security Agency treated it as urgent. CISA added CVE-2026-16232 to its Known Exploited Vulnerabilities catalogue on 22 July. Federal agencies had until 25 July, a three-day window, to remediate. That is one of the tighter deadlines CISA sets. It is reserved for bugs the agency judges are being weaponised fast, putting this SmartConsole authentication bypass in the same bracket as Palo Alto’s GlobalProtect authentication bypass, which went from advisory to active exploitation in just four days.
The same 22 July Jumbo Hotfix round also closed two related bugs, CVE-2026-62144 and CVE-2026-62145. Both affect the same R81.10, R81.20, R82 and R82.10 release families. Check Point has not said either is under active attack the way CVE-2026-16232 is. But patching one and leaving the others open on the same server defeats the point of an emergency update. Anyone pulling the Jumbo Hotfix for the authentication bypass gets all three fixes in one package, so there is no reason to patch selectively.
What to check right now
Organisations exposed to this SmartConsole authentication bypass should treat the fix as an emergency patch, not routine maintenance. Check Point’s fixed builds are Jumbo Hotfix Take 158 or later for R81.20, Take 118 or later for R82, and Take 36 or later for R82.10. Older branches, including R81.10, R80.30 and R77.30, remain listed as affected with no dedicated fix. Isolating those management servers from untrusted networks matters even more as a result.
Beyond patching, Check Point’s own guidance is worth following to the letter. Restrict Trusted Clients to specific, known IP addresses or subnets. Put a firewall in front of management access rather than exposing it directly. Confirm the implied rules that govern control connections are switched on. None of that is exotic advice. It is the baseline that a default configuration apparently failed to enforce.
Rapid7’s PoC is a useful diagnostic here, not just an attack tool. Run against a management server, it reports whether the target is vulnerable or already patched. That gives security teams a fast way to confirm a hotfix actually landed, instead of assuming the change control ticket did its job. The same dynamic followed vBulletin’s pre-auth RCE a few days earlier. Once a working exploit script goes public, the pool of attackers able to use it grows fast, whatever the original in-the-wild numbers looked like.
The wider lesson
Firewall management consoles are meant to be the most locked-down box on the network, since whoever controls them controls every policy behind them. This SmartConsole authentication bypass is a reminder that a “trusted by default” setting on that console is a liability the moment it faces the internet. Teams that manage Check Point infrastructure should verify patch status today, not after the next change window. The proof-of-concept is already circulating, and CISA’s own deadline has already passed for federal networks.
The SmartConsole authentication bypass matters well beyond the handful of customers already hit. Check Point’s Security Management platform sits behind a large share of enterprise firewall estates. Every organisation running an affected build should confirm the hotfix is installed and the Trusted Clients list is locked down, whether or not its console currently faces the internet. A quiet weekend of patching now beats explaining an incident later, especially once a validated exploit script sits in a public GitHub repository for anyone to pick up.