CVE-2026-118527：连 CISA 自己的目录都解释不清的那个 Ivanti 漏洞

CISA 为同一条利用链新增了两个 CVE 编号，却没能把其中一个解释清楚

大家都把一次 KEV 新增，当作某个漏洞终于被解释清楚的时刻。CISA 自己为 CVE-2026-118527 撰写的目录条目，做的却恰恰相反：它说这个漏洞确实存在，说它和同一台设备上的另外两个 CVE 构成利用链，却在真正说清楚这到底是什么之前就戛然而止。[4]

就在我写完 CVE-2026-104935——Volexity 在一台已经打满补丁的 Ivanti Connect Secure 设备上还原出的那条从 welcome.cgi 直通 root 的利用链——两周之后，CISA 又为同一条利用链新增了两个 CVE 编号，同样都在 2026 年 10 月 30 日这一天加入已知被利用漏洞目录：CVE-2026-111357 和 CVE-2026-118527。[3][4] 其中一个，补上了第一篇文章留下的一个缺口；另一个，则打开了一个新的缺口。

CVE-2026-111357 是干净的那一半：终于给我已经讲清楚的机制起了个名字

第一篇文章描述过一个既没有 CVE 编号、也没有补丁的提权阶段：攻击者一旦以无特权用户 cgi-server 的身份获得了代码执行能力，就能够通过修改某个共享库在内存中的副本，重新指向 dsinvoked——ICS 自身具备 root 权限的任务执行进程。这个阶段现在两样都有了。Ivanti 在 2026 年 10 月 29 日发布了修复，Volexity 自己的更新说明把它命名为 CVE-2026-111357。NVD 的描述独立印证了同一个机制：dsinvoked 这个代理进程信任 DSCache 的配置数据，从而导致提权至 root。[1][2]

CISA 自己的取证分级标记，透露出它对这条利用链里每个 CVE 的实际态度：对 CVE-2026-104935 和 CVE-2026-111357，依据第 26-04 号强制运营指令，取证是强制要求；对 CVE-2026-118527，则不是强制要求。[5][3][4] 至于 CISA 认为第三个 CVE 到底有多确定，您可以自己下结论。

// KEV catalog entries for this chain, read directly from CISA's own catalog pages.

CVE-2026-104935   added 2026-10-13   due 2026-10-16   forensic triage: required
CVE-2026-111357   added 2026-10-30   due 2026-11-02   forensic triage: required   (Ivanti's patch shipped 2026-10-29)
CVE-2026-118527   added 2026-10-30   due 2026-11-13   forensic triage: not required

// Same chain, three different clocks, and CISA treating the third CVE
// differently from the other two without saying why in the catalog entry itself.

CVE-2026-118527 和 Volexity 写过的任何内容都对不上

CISA 给 CVE-2026-118527 的简短描述，读起来像是第一篇文章里某个漏洞的通俗版本：一名远程且已认证的攻击者，可以把自己控制的内容上传到磁盘上一个已知的位置。[4] 这和 wu.cgi 那个“先写入、后校验”的竞态已经非常接近——它会把上传的文件写到一个由 MD5 推导出的、可预测的路径，再去检查内容。接近，但并不完全一致。Volexity 的文章，无论是原文还是更新说明，一次都没有提到过 CVE-2026-118527。[1] 而 CISA 说这个漏洞需要一名已认证的攻击者。wu.cgi 那条竞态本身却是未认证就能触达的，走的是开启整条利用链的 welcome.cgi 请求头技巧。

这两件事哪个是真的，我并不知道：CVE-2026-118527 究竟是给 CVE-2026-104935 已经覆盖过的漏洞另起的一个新编号，还是一个确实独立、迄今没有任何人公开描述过的可预测路径问题。Ivanti 自己的公告原本可以用一句话说清楚这件事，但在两次独立的调查尝试中——由两个不同的人分别进行、沿着不同路径——都没能打开。这是一个持续存在的障碍，不是一个“晚点再试就好”的缺口。除非这一点发生变化，或者 Ivanti 把公告重新发布到别的地方，这个问题就一直保持开放。我更愿意把这一点说清楚，而不是去猜测，然后在任何一个方向上猜错。

一家媒体给出的三阶段顺序，Volexity 自己的报告并不支持

还有第二条没理清的线索。一家报道了 10 月 30 日 KEV 新增条目的聚合媒体，给出了一个具体的利用链顺序：先是未认证的 RCE（CVE-2026-104935），再是已认证的文件植入（CVE-2026-118527），最后才是提权（CVE-2026-111357）——仿佛这个较新的 CVE 是刻意安排的中间步骤。Volexity 自己的报告并不是这样讲的。它是从 wu.cgi 的 RCE 直接跳到 dsinvoked 的提权，中间并没有描述过任何独立的文件植入阶段。[6][1]

要么是这家媒体掌握了 Volexity 文章里从未提到的、来自 Ivanti 公告的细节，要么它就是单纯说错了，而我在这里无法判断究竟是哪一种。我不会为了挑一个读起来更顺的版本，就把这个分歧抹平。同一篇报道还在正文里给出了两个不同的 CVE-2026-111357 CVSS 评分——一处是 7.0，另一处是 8.8——并给 CVE-2026-118527 标出 4.3 分，而它自己的对比表格却又单独把这个分数列为“等待分析”。[6] 除了 NVD 自己给出的 CVE-2026-111357 评分 7.0 以外，这两个 CVE 的任何其他分数都应当视为未经证实，因为目前情况正是如此。[2]

无论这两个问题有没有答案，对您来说真正改变了什么

无论如何都要打补丁。针对 CVE-2026-104935 的第一轮修复，已经堵上了 welcome.cgi 和 wu.cgi 两个阶段；具体的版本号我在第一篇文章里列过，这份清单没有变化。dsinvoked/DSCache 这个阶段需要一个独立的更新，现在被记录为 CVE-2026-111357，Ivanti 已于 2026 年 10 月 29 日发布。这个编号的联邦修复截止日期是 2026 年 11 月 2 日——也就是我写下这几行字的今天。[1][3] CVE-2026-118527 的截止日期则是 2026 年 11 月 13 日，而且和另外两个不同，CISA 自己的取证分级标记把它标为“非强制要求”，依据的是第 26-04 号指令。[3][4][5]

不要因为身份问题悬而未决，就让自己选择等待。无论 CVE-2026-118527 最终被证实是一个新漏洞，还是一个被重新编号的旧漏洞，修复路径都是一样的：使用当前版本，参照当前公告，并且不要仅凭 Integrity Checker Tool 的一次干净结果，就宣布事件已经了结。第一篇文章里提到的这条限制，至今没有改变。

// What this update actually settles, and what it doesn't.

SETTLED
  - CVE-2026-111357 is the dsinvoked / DSCache privilege escalation
    described in the original piece. Ivanti patched it on 2026-10-29.
  - CISA added both new CVEs to the KEV catalog on 2026-10-30.

NOT SETTLED
  - Whether CVE-2026-118527 is a new bug, or an existing one (the wu.cgi
    predictable-path upload) given its own CVE number.
  - Which chain order is correct: Volexity's (RCE straight to privilege
    escalation) or the three-stage order one outlet reported, with
    CVE-2026-118527 as a separate step in between.
  - Any CVSS score for CVE-2026-118527. NVD has no record for it as of
    this writing.

一条尚未解决的 KEV 条目，不是您可以视而不见的遗留问题

这次更新的真实情况，比围绕它的喧哗要简单得多：一个新的 CVE 编号，补上了我两周前指出的那个缺口；另一个新的 CVE 编号，则打开了一个 CISA 自己的目录都没有回答的问题。这两件事同时成立，谁也没有否定谁。

这正是我在为客户验证补丁时，一直在寻找的那类缺口：不是看工单上的 CVE 有没有被关掉，而是看每一个曾被归到某条利用链里的机制，是否真的被修复了——包括那些至今还没有人完整描述过的机制。如果您手上正运行着一台 Ivanti Connect Secure 设备，想找人核实这一点，核对它和真实运行情况是否一致，这正是我在做的工作。