Security & Threat Intelligence · 07.08.2026, 16:25 UTC
Rapid7 Analysis: Check Point SmartConsole Authentication Bypass (CVE-2026-16232)
| Schweregrad | high aktiv ausgenutzt (KEV) |
|---|---|
| CVE | ↗ |
| Kategorie | Security & Threat Intelligence |
| Quelle | Rapid7 Blog ↗ |
| Veröffentlicht | 07.08.2026 UTC |
Sicherheitsmeldung mit Schweregrad noch nicht bewertet. Betroffene Kennungen: CVE-2026-16232. Technische Details im Tab „Originaltext“; empfohlene Schritte in der Checkliste.
OverviewOn July 22, 2026, Check Point published a security advisory for CVE-2026-16232, an authentication bypass in the SmartConsole login process affecting Security Management Server and Multi-Domain Security Management Server (MDS). By leveraging CVE-2026-16232, an unauthenticated attacker can obtain an application login token, use this token to log in through SmartConsole with full administrator privileges, and modify the security policy or security configuration. Exploitation requires network access to the Management Server and for a Trusted Clients configuration that does not restrict GUI clients, which in our testing was a default setting. This vulnerability was reported as being exploited in the wild as a zero-day vulnerability at the time of disclosure.Our analysis finds that the root cause of CVE-2026-16232 is a broken trust boundary in the application authentication path. A vulnerable server accepts an attacker-supplied Secure Internal Communication (SIC) distinguished name (DN) as the identity of a remote application instead of binding that identity to the authenticated remote peer certificate DN returned by getCertificateDnName(). An attacker can read the management server's own SIC DN during the unauthenticated bootstrap communication, replay that DN in a forged application certificate bind, obtain an application token, and then ask the legacy management service to mint a new SmartConsole single sign-on (SSO) ticket.Rapid7 Labs has reproduced CVE-2026-16232 against affected R81.20 and R82.10 versions of the target software. Our proof-of-concept (PoC) exploit …