Overview On 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 script can be used to successfully validate if a target is either vulnerable or patched. The vendor supplied patches have been confirmed to successfully remediate the vulnerability and prevent our PoC script from succeeding. Analysis SmartConsole is the desktop client administrators use to manage Check Point policy and configuration. A SmartConsole login crosses two generations of management plumbing over the network. The first is the legacy FWM/CPMI service, listening on TCP 18190 . It uses SIC, Check Point's certificate-based trust mechanism for communication between management components. Once the SIC bootstrap completes, FWM exchanges length-prefixed “FwSet” objects, a Check Point name/value encoding used by older management services. The second is the newer CPM/DLE service. This exposes SOAP services over HTTPS on TCP 19009 under the URI path /cpmws/ . SmartConsole uses these services for login, queries, and object operations. Authenticated requests carry DLESESSIONID and CLIENTSESSIONID header values to prove a client is authenticated. The exploit for CVE-2026-16232 uses both the FWM/CPMI and CPM/DLE services. It first uses the native FWM/CPMI protocol to claim an application identity and obtain an application token via the root cause of the vulnerability. It then uses the accepted native application session to ask FWM for a SmartConsole SSO ticket, redeems the ticket over CPM's SOAP API, and receives a SmartConsole session. The diagram below shows the flow for exploiting CVE-2026-16232. Figure 1: Flow diagram of exploitation. The application authentication boundary The Java login service contains a bridge for FWM application based logins. The authenticateUser method splits the supplied username into an application name and a SIC DN, then passes both into cpApplicationAuthentication() . // Source: work/t146/mgmt_wrapper.tgz:fw1/cpm-server/dleserver.jar.full!/com/checkpoint/management/dleserver/coresvc/internal/LoginSvcImpl.class

private AuthenticationResponse authenticateUser(AuthenticationInfoBase authenticationInfoBase, String string, String string2, CPUUID cPUUID, boolean bl, LockAdminInfoContainer lockAdminInfoContainer, ExternalLoginInfo externalLoginInfo) throws AuthenticationFailureLoginException, LicenseExpiredLoginException {

// ...

} else if (authenticationInfoBase instanceof FwmAuthenticationInfo) {     object2 = authenticationInfoBase.getUsername(); int n = ((String)object2).toLowerCase().lastIndexOf("cn=");     object = (FwmAuthenticationInfo)authenticationInfoBase; if (FwmLoginType.APPLICATION.equals((Object)object.getFwmLoginType())) { String suppliedSicDn = ((String)object2).substring(n); // <-- [1] String applicationName = ((String)object2).substring(0, n - 1); // <-- [2] TdLog.debug((CPLogger)c, (String)"Authenticating FwmAuthenticationInfo on behalf of application {}", (Object[])new Object[]{applicationName});        CPApplicationAuthenticationInfo cPApplicationAuthenticationInfo = new CPApplicationAuthenticationInfo();        cPApplicationAuthenticationInfo.setUsername(applicationName); this.cpApplicationAuthentication((AuthenticationInfoBase)cPApplicationAuthenticationInfo, suppliedSicDn, cPUUID);// <-- [3] authenticationInfoBase.setUsername(applicationName); At [1] and [2] , the login service treats attacker-controlled input as both the application name and the claimed SIC identity. At [3] , the untrusted DN claim reaches the remote application authenticator as a separate argument. The method that consumes that identity is authenticateRemoteApplication() . This method prefers the attacker-supplied DN whenever one is present. // Source: work/t146/mgmt_wrapper.tgz:fw1/cpm-server/dleserver.jar.full!/com/checkpoint/management/dleserver/coresvc/internal/LoginSvcImpl.class

private void authenticateRemoteApplication(String applicationName, String suppliedSicDn) throws AuthenticationFailureLoginException { String effectiveSicDn = suppliedSicDn == null          ? this.j.getCertificateDnName()         : suppliedSicDn; // <-- [1] CpAssert.cpassert(StringUtils.isNotEmpty(effectiveSicDn), "User DN name is not set"); if (effectiveSicDn.equals("CN=siclocal")) { this.authenticateLocal(applicationName); } else { this.t.identifyDomainForRemoteLogin(effectiveSicDn); // <-- [2] } } The problem is at [1] . The vulnerable code collapses the untrusted claim and the authenticated peer identity into one variable. If suppliedSicDn is present, the code never uses getCertificateDnName() at all. The method then uses the attacker-controlled value at [2] to identify the login domain. In practice, a remote client can copy the management server's own SIC DN into :DN and authenticate as a remote application without presenting a client certificate for that identity. What the patch changes Our analysis compares the decompiled com.checkpoint.management.dleserver.coresvc.internal.LoginSvcImpl class from a vulnerable “R81.20 Jumbo Hotfix Take 146” against the patched “R81.20 Jumbo Hotfix Take 158”. private void authenticateRemoteApplication(String applicationName, String suppliedSicDn) throws AuthenticationFailureLoginException {

  • String effectiveSicDn = suppliedSicDn == null
  •    ? this.j.getCertificateDnName()

  •    : suppliedSicDn;                                      // <-- [1]
  • CpAssert.cpassert(StringUtils.isNotEmpty(effectiveSicDn), "User DN name is not set");
  • String effectiveSicDn;
  • String certificateDn = this.j.getCertificateDnName();
  • String remoteIp = this.j.getRemoteIpAddress();
  • boolean localSic = IpUtils.isLoopback(remoteIp) && "CN=siclocal".equals(certificateDn);
  • if (localSic && suppliedSicDn != null) {
  •    effectiveSicDn = suppliedSicDn;                       // <-- [2]
  • } else {
  •    effectiveSicDn = certificateDn;                       // <-- [3]

  •    boolean mismatch = suppliedSicDn != null

  •        && StringUtils.isNotEmpty(certificateDn)

  •        && !suppliedSicDn.equalsIgnoreCase(certificateDn);

  •    if (mismatch) {

  •        TdLog.error(c,

  •            "Rejecting caller-supplied SIC name that does not match the client certificate DN for application {} from {}",

  •            applicationName, remoteIp);

  •        throw new AuthenticationFailureLoginException(

  •            "Remote authentication failed