RootGS 安全观察｜发布日期：2026 年 11 月 1 日｜资料核验截至当天（UTC+8）
远程支持平台通常能接触大量受管终端。它的漏洞处置不能只看设备是否重新上线，还要确认管理入口、历史访问和凭据是否可信。CVE-2026-102764 提醒运维团队：堵住入口与排除既有入侵，是两项不同的工作。
一、已确认的漏洞事实与利用证据
BeyondTrust 于 10 月 15 日发布 BT26-05：CVE-2026-102764 的 CVSS v4.0 评分为 9.3，涉及 Remote Support 内部消息来源校验不足，可在特定条件下导致设备文件操作。受影响版本为 26.2.3 及更早版本。BT26-05 官方公告。
Mandiant 的一线响应报告记录了 8 月下旬的零日利用，并描述攻击后的持久化活动。因此本文讨论的是有真实利用证据的事件，而非仅依据评分推测的风险。Mandiant 事件分析。
二、为什么远程支持设备应被单独列为关键资产
以下是面向运维的风险分析：当某个平台承担终端连接、文件传输或凭据代理职责时，它与普通展示网站的影响范围不同。应按实际授权评估其可触达的服务器、用户组和网络区域，而不是简单用设备数量衡量风险。
第一份清单应记录设备的公网域名、管理地址、部署模式、当前版本、维护负责人和连接范围。第二份清单记录它能访问的终端组与托管凭据。如果设备仅在内网，也要检查合作方接入、VPN 路径和临时端口映射；“没有放在首页”并不等于没有入口。
三、SaaS、自建以及 PRA 应分别核实
官方公告说明，Remote Support SaaS 已于 10 月 9 日前应用修复；自建实例需确认自动更新状态，或手动安装 BT26-05-RS。该补丁面向 24.3.1 至 26.2.3，旧于 24.3.1 的版本需先升级。主版本号相同不代表补丁状态相同，应保留补丁安装记录。
厂商另行说明：Remote Support 已确认受影响；Privileged Remote Access 共享相关代码，厂商提供预防性补丁，但当时内部测试尚未发现其可被同样利用的方式。不能把二者写成“已确认受到相同攻击”。厂商事件说明与 PRA 边界。
对 SaaS 用户，处置重点是取得供应商修复确认并检查租户访问记录；对自建用户，补丁安装、设备健康检查及调查证据保全都需要自己落实。
四、把修补工作与入侵调查并行安排
Mandiant 报告记录了 WebShell、隧道工具及日志清理等入侵后行为。这说明补丁只能阻止相关入口继续被利用，不能自动删除已存在的驻留程序，也不能让已经暴露的凭据重新保密。
建议先保留设备日志、配置导出和可获得的完整性信息，再按照厂商支持流程升级或隔离。不要为了“清理干净”直接删除异常文件或重置设备，因为那可能破坏用于确定影响范围的证据。需要重建时，先确认备份是否可信，明确恢复内容，避免把可疑配置一并带回。
调查关注异常文件变更、非预期启动项、陌生管理会话、异常出站连接与时间线缺口。设备可能限制底层访问，应通过供应商支持获取日志；不要擅自关闭设备保护机制来执行网上流传的检查脚本。
五、凭据轮换要建立在可信访问路径上
若调查确认或高度怀疑设备被控制，先收敛对外入口与管理权限，再从可信终端安排轮换。应按实际暴露范围检查管理账号、API 凭据、存储或代理的终端凭据及仍然有效的会话。仅修改一个管理员密码，无法覆盖所有可能的访问路径。
轮换顺序需要兼顾业务依赖：先列出使用方，准备替代访问方式，再逐项更新、验证与撤销旧值。不要通过仍被怀疑失陷的设备下发新凭据。对于无法立即替换的接入，应设定限时隔离措施并明确负责人。以上为通用事件响应建议，不表示所有设备都发生了凭据泄露。
六、怎样定义这次处置已经完成
建议把验收拆成四项：官方修复已应用；未知管理会话与异常驻留已调查；必要的凭据和会话已轮换或失效；远程支持功能在受控范围内恢复并通过业务确认。每项都有对应证据，才能避免“补丁成功”被误当成“入侵排除”。
对于没有发现异常的环境，同样保留核查时段、日志覆盖范围及检查方法。若历史日志不足，应写明调查结论的边界，而不是直接宣布从未受到攻击。此类高权限平台的长期改进重点，是最小授权、分区连接和可独立保存的审计日志。
参考资料与阅读边界
文中漏洞事实以对应官方公告为依据；处置优先级、排查顺序和验收清单为 RootGS 运维分析。CVSS 是技术严重程度评分，不代表每台服务器都已遭攻击。
