Volexity 在 10 月 13 号挂了一篇博客，标题叫 A Series of Unauthenticated Events，讲的是他们盯到的一件事：有人拿一串 Ivanti Connect Secure 的洞，把一套 VPN 门从外面一路打穿到 root。CISA 当天就把第一个（CVE-2026-104935）收进了 KEV；到 10 月 30 号，同一封警报又更新，把另外两个（CVE-2026-111357、CVE-2026-118527）一起补了进去。

之所以值得单拎出来，是因为这三个洞不是各打各的，是能串成一条链的：

  • CVE-2026-104935（CVSS 8.6）：ICS 上认证绕过，用伪造就能把闸机让过去，远程、不需要账号就能执行任意命令；官方修在 25.1.3.0，且在 22.7R2.14 及更早不受影响。
  • CVE-2026-118527：生成可预测的数/标识符，让远程已认证的攻击者能把 attacker 控制的文件上传到磁盘上一个已知位置。
  • CVE-2026-111357（CVSS 7.0）：ICS 22.8R2.4 里 dsinvoked broker 对 DSCache 配置数据的信任方式不对，本地已认证的攻击者能提权到 root。

串起来的顺序也顺：先用 104935 绕过认证进来，再用 118527 上传落文件，最后靠 111357 提到 root。一个负责「进得来」，一个负责「放得进」，一个负责「站得稳」。

CISA 的措辞不绕弯：已经观测到攻击者在利用这几个洞，用来自动执行任意命令、偷凭证、外传数据。

影响版本（CISA 10 月 30 日更新的口径）：Ivanti Connect Secure 25.1.1.2 及更早、25.1.2.2 及更早、22.8R2.5 及更早，都在受影响范围内。

有两条比版本号更让人心里没底。第一，Ivanti 自家的完整性检查工具 ICT（Integrity Checker Tool）可能查不出 104935 被利用过的痕迹——因为攻击者的命令是在内存里执行的，不落盘，事后扫文件扫不出来。第二，22.8 这条线明年 1 月 31 号就 EOL 了；还在跑 22.8 的，其实是在一条快到头的线上等补丁。

一条自查：版本从管理台看，曝露面从外面探——

# 从任一机器探一下这台 VPN 门是不是摊在公网上（有响应就说明在暴露面里）
curl -sk -o /dev/null -w 'HTTP %{http_code}\n' https://<ICS地址>/dana-na/auth/url_default/welcome.cgi

# 版本：登录管理台 → System > Maintenance > System Status，看 Version 那一行
# 对照：25.1.1.2 / 25.1.2.2 / 22.8R2.5 及更早 = 在受影响范围

真怀疑中招了，CISA 给的处理顺序是一套完整动作，别只重启了事：先备份设备配置 → 恢复出厂并升到最新版 → 云上/虚拟的整台重建实例 → 把第 1 步的配置恢复回来 → 把所有账号口令（域账号、管理员、本地）、证书、API key、License 服务器凭证全部重置重发。光是「升个级」不够，因为内存里跑过的命令、被偷走的凭证，不会随升级一起消失。

对做运维的来说，这类洞的难受点在于：VPN 门常常是整套环境里唯一对着公网的入口，一旦它被打穿，后面的内网基本就是平地。之前写过一台被拿下的机器顺着 Tailscale 的 SSH 转发摸到别人的 root，路径不一样，道理一样——边界上那一个口子，值不值得多花十分钟看一眼版本。同样的「不用账号就能进」的套路，前段时间的 PHP2Shell 也是一条链的起点。

来源：CISA 警报（10 月 30 日更新）＋ Volexity 博客《A Series of Unauthenticated Events》＋ Ivanti 安全公告（hub.ivanti.com）。