Check Point SmartConsole曝零日漏洞 可获完全管理员权限 PoC已公开

Check Point SmartConsole 管理界面中被确认存在一个已被积极利用的零日身份验证绕过漏洞，攻击者可在无需任何凭证的情况下获得完整管理员权限。该漏洞跟踪编号为 CVE-2026-16232，影响 Security Management Server 和 Multi‑Domain Security Management Server（MDS），在补丁可用之前就已遭到野外利用。

2026 年 7 月 22 日，Check Point 发布安全公告详细说明了这一问题。同一天，Rapid7 Labs 确认了漏洞的野外利用情况，并公开了一份概念验证（PoC）脚本，用于帮助防御者评估自身暴露面。这意味着已经出现可复现的攻击代码，未打补丁的系统面临迫在眉睫的风险。

漏洞位于 SmartConsole 的登录路径中。只要攻击者能够通过网络接触到管理服务器，就可以获取一个应用登录令牌，然后通过 SmartConsole 以完整管理员权限完成身份验证，进而修改安全策略或系统配置。成功利用的典型前提是管理平面存在网络可达性，且“可信客户端”设置没有严格限制 GUI 客户端——Rapid7 在测试中发现，这是默认配置。因此，大量对外暴露管理接口的组织在完成修补和访问加固之前，都处于高风险状态。

根据 Rapid7 的分析，问题的根本原因在于应用身份验证中存在一个被打破的信任边界。正常流程中，远程应用的身份应当与平台返回的已认证对端证书所绑定的身份一致。然而，受影响的服务器却会接受攻击者提供的 SIC（Secure Internal Communication）专有名称（Distinguished Name，DN）作为远程应用的身份，而不是将该身份与实际证书绑定。这种设计缺陷为攻击者打开了一条冒用身份的通道。

SIC 是 Check Point 内部组件之间实现安全通信的基础机制，依赖证书对等体完成双向身份认证。在此次攻击场景中，攻击者并不需要窃取或破解任何证书，而是利用协议交互的漏洞来伪造身份声明。

整个攻击链条可以分解为四个紧密衔接的阶段：

第一步，攻击者在未经身份验证的引导流量中获取管理服务器自身的 SIC DN。由于引导阶段的信息交换并不要求先完成认证，攻击者能够被动或主动地向服务器请求到这一标识符；

第二步，攻击者用获取到的服务器 SIC DN 伪造一个应用证书绑定请求。受影响的服务器未能校验该声明与真实证书之间的绑定关系，而是直接认可攻击者提交的 DN，从而错误地将攻击者视为一个合法的远程应用；

第三步，服务器在误认身份后向攻击者发放一个应用令牌。这个令牌本质上是旧版管理服务在信任链条被污染后颁发的一个会话凭证；

第四步，攻击者拿着这个应用令牌，向老旧的 FWM/CPMI 服务请求一个 SmartConsole 单点登录（SSO）凭据，再将该凭据通过较新的 CPM SOAP API 进行兑换，最终获得一个具有管理员权限的完整 SmartConsole 会话。

SmartConsole 的管理流量横跨两代服务架构。旧版 FWM/CPMI 服务运行在 TCP 18190 端口，负责处理基于 SIC 的信任关系和早期的 FwSet 风格操作交互；新版 CPM/DLE 栈则工作在 TCP 19009 端口，在 /cpmws/ 路径下暴露 SOAP 操作，登录后依赖会话头部维持状态。此次零日攻击的精妙之处在于链式利用了这两代服务：首先在 FWM/CPMI 层面冒用应用身份获取令牌，然后跨到 CPM SOAP 环境生成并兑换 SSO 票证，从而将一套残缺的信任关系串联成一个完整的管理员权限入口。

一旦攻击者拿到有效的会话标识，就可以执行多项特权操作，包括读取服务器详细信息、枚举所有管理员账户，以及修改各类安全策略与配置。这意味着攻击者不仅可以偷看网络防御布局，还能直接关闭防护规则、开放后门或横向移动至其他管理域，尤其是在 MDS 环境下，一个管理服务器的沦陷可能波及多个安全域。

对于防御者来说，一个可操作的检测指标已经浮现。审计日志中如果出现认证方式标记为“application token”的记录，就可以将其视为潜在的入侵痕迹。正常情况下，管理员登录 SmartConsole 通常使用的是用户名口令或证书认证，而不应该出现应用令牌方式的登录。因此，安全团队可以据此构建告警规则，快速筛查异常活动。

Rapid7 已经在受影响的 R81.20 和 R82.10 版本上复现了该问题，并在 GitHub 上公布了 PoC 脚本。该脚本可以验证目标是否存在漏洞，或者是否已经修补完成，帮助机构无需猜测即可判断自己所面临的真实风险。

Check Point 提供的修复方案直接切断了攻击链的核心环节：强制要求远程应用的身份验证必须使用证书绑定的对端 DN，而不再接受攻击者提交的任意 DN 声明。这一改动恢复了身份与证书之间的绑定关系，使得攻击者无法再通过伪造 SIC DN 来获取应用令牌。官方建议所有运行受影响版本的用户立即应用补丁，同时审查管理接口的访问控制，确保“可信客户端”设置为仅允许已知的、受控的 GUI 客户端，并将管理服务器置于严格的网络隔离之后，避免直接暴露在不受信任的网络中。

考虑到该漏洞在被公开披露前已有活跃利用，延迟修补的每一小时都可能意味着一次成功的入侵。结合 Rapid7 公开的检测与验证工具，安全运维人员应尽快执行以下三项动作：验证补丁状态、在网络层限制管理平面可达性、以及回溯审计日志中是否存在“application token”认证方式的记录。只有同时完成修补、访问控制和事件排查，才能完全消除该零日漏洞带来的管理员权限失控风险。