CISA 于 10 月 30 日（周五）将两个 Ivanti Connect Secure 漏洞加入已知被利用漏洞目录：CVE-2026-111357（CVSS 8.8）与 CVE-2026-118527（CVSS 4.3）。二者与 10 月 13 日入册的 CVE-2026-104935（CVSS 8.6）构成一条已被实际使用的完整利用链，最终效果是未认证的 root 级代码执行。关键点在于：10 月 13 日刚打完补丁的设备，仍然卡在这条链的中间。
事件概述
这条链最早由 Volexity 在 10 月 13 日记录，攻击者被追踪为 UTA0576，活动时间从 10 月 3 日开始，被入侵的设备当时已经是全补丁状态（22.8R2.4）。Volexity 的描述是：认证绕过、远程代码执行、权限提升三个环节串联，达成未认证 root 级代码执行。
Ivanti 的处境有些尴尬。发现利用活动时，CVE-2026-104935 的修复刚好在 QA 阶段，厂商决定不推迟发布，先把主利用路径堵上，于是 10 月 13 日放出了 25.1.1.2 与 22.8R2.5。这两个版本只修了第一环。真正的完整修复在 10 月 29 日发布的 25.1.1.3 与 22.8R2.6 中。
受影响版本为 25.1.1.2 及更早、25.1.2.2 及更早、22.8R2.5 及更早。CVE-2026-111357 那一环此前已在七月版 25.1.3.0 中修掉，属于厂商自身产品安全计划的产出，其他分支的回溯补丁直到这次才补齐。
技术细节
三个环节的分工相当清晰，值得逐条看清：
- 第一环 CVE-2026-104935，认证绕过。攻击者向公开的登录脚本
/dana-na/auth/url_default/welcome.cgi发请求，同时带一个X-DSCGI-PATH头，指向另一个受保护的脚本。设备按 URL 判断这个请求该不该放行，却按请求头决定把请求送到哪里，两个判断不一致，认证就被绕过了。 - 第二环 CVE-2026-118527，可预测路径上传。上传处理程序
wu.cgi把文件写到/home/runtime/tmp/下，文件名取客户端提供文件名的 MD5，写完之后再检查是不是 ZIP，不是就删掉。攻击者上传一个 Perl 脚本，同时对那个可预测的路径发起并发请求，抢在删除动作之前把脚本执行掉。 - 第三环 CVE-2026-111357，本地提权到 root。
dsinvoked代理以 root 身份运行维护任务，每个任务执行哪个程序是从 DSCache 这个共享配置存储里查的。攻击者改掉内存中libdsplibs的副本，让维护任务去跑自己指定的程序。
值得注意的是攻击者的目标并不是常见的植 webshell 或投勒索。UTA0576 的行为集中在窃取凭据与有限的 Active Directory 元数据、做主机侦察、搜索管理员密码与 BitLocker 恢复密钥。这是典型的长期驻留、横向移动前置准备。
影响评估
Ivanti Connect Secure 处在几个条件的交叉点上：设计上必须暴露在公网、终结大量高权限用户的认证、又在过去几年反复出现可串联的高危漏洞。一旦被打穿，攻击者获得的是「不用任何凭据就能在边界设备上以 root 执行命令」的位置。
联邦文职行政部门（FCEB）的处置期限已经明确：CVE-2026-111357 为 11 月 2 日，CVE-2026-118527 为 11 月 13 日。22.8 分支将于 2027 年 1 月 31 日停止支持，仍在用这个分支的应当把迁移排进计划。
特别提醒一处检测盲区：Ivanti 的完整性检查工具（ICT）可能查不出利用痕迹，因为攻击者的命令在内存中执行。这意味着 ICT 显示「干净」不能作为设备未被入侵的证据，必须做网络与内存取证。
修复建议
- 升级到 25.1.1.3 或 22.8R2.6，从 Ivanti License System 下载后在管理控制台的 Maintenance → System → Upgrade/Downgrade 逐节点安装。25.1.3.0 及以上版本已包含全部三环修复。
- 升级前先留证据。这次升级会重启设备，而这条链上有价值的痕迹大多在内存里，先做内存镜像再动手。
- 怀疑已被入侵的，按厂商恢复流程处理：备份配置、恢复出厂设置、升级到最新版、从备份还原配置，然后重置所有账户密码（含域账户、管理员账户、本地账户），吊销并重签证书，重置存储的 API Key 与许可服务器凭据。
- 假设已被入侵来排查：拉取 30 至 90 天的认证日志与会话建立记录，找异常管理员会话、新建本地账号、非预期配置变更、来源异常的 IP。
- 暂时无法升级的，把设备挪到强制 MFA 的反向代理之后，管理接口只开给专用管理网段。
这类边界设备的历史规律是：补丁发布到公开 PoC 出现的间隔很短，而设备又长期暴露。等下周再排期的代价，通常比一次紧急变更高得多。