2026 年 10 月 13 日，CVE-2026-104935 的官方紀錄公開，CISA 同日將其加入已知遭利用漏洞目錄（KEV）。對維運團隊而言，今天應啟動的是受影響設備盤點與修補排程。KEV 身分已有官方資料支持，不能把它只當成尚待驗證的概念驗證風險。[1][2]

先把漏洞性質說清楚

Ivanti 在 CVE 紀錄中將問題歸類為 CWE-290，即以偽冒方式繞過身分驗證；遠端、未經驗證的攻擊者可因此執行任意命令。CVSS 3.1 分數為 8.6，等級為 High。應區分漏洞成因與影響：這份紀錄的分類是驗證繞過，不能自行改稱作業系統命令注入。[2]

修補目標必須對應原有分支

愛爾蘭 NCSC 的公告列出以下對應關係：[3]

  • 25.1.1.1 及該分支較早版本：修補版本為 25.1.1.2。
  • 25.1.2.2 及該分支較早版本：修補版本為 25.1.3.0 或 25.1.3.1。
  • 22.8R2.4 及該分支較早版本：修補版本為 22.8R2.5。
  • 公告明確說明，22.7R2.14 及更早版本不受本漏洞影響。

版本號不能跨分支做單純大小比較。另有一項資料差異：CVE JSON 的未受影響版本列舉未包含 25.1.1.2，NCSC 表格則明列此修補版本；本文保留來源差異，不自行把兩者合成沒有例外的範圍。尤其 CVE 結構化欄位與文字描述的粒度不同，不能只把「預設受影響」轉成所有舊版皆有漏洞的結論。執行升級前，仍應用設備的完整版本核對 Ivanti 最新公告與支援的升級路徑。[2][3]

工程處置：把每台設備變成可追蹤項目

以下是依上述風險提出的維運建議，並非廠商公布的專用鑑識程序。本文未操作實際設備、測試漏洞或執行升級。

第一步，建立逐台清單，記錄設備識別、目前完整版本、服務用途、對外暴露情況、負責人與預定修補時間。不要只記錄叢集名稱；主用、備援及災難復原節點都應各有一筆。無法讀取版本的設備應標為待確認，避免在報表中被誤算為不受影響。

第二步，安排變更前先確認備份、維護窗口、回復條件及必要的人員。依官方支援流程安裝對應修補版本；若業務限制使設備無法及時升級，應明列限制、暴露範圍與負責決策的人，交由風險責任人處理，避免工單只留下「稍後更新」。

第三步，把完成條件寫成可驗收結果：每個節點回報的版本符合目標、必要的遠端存取功能通過驗證、備援狀態正常，並附上執行時間與核對人。下載安裝檔、排定維護或按下升級，都還不是完成證據。

讓修補報表能被接手

若多個團隊共同管理遠端入口，建議用同一份清單交接。欄位至少區分「不受影響且已核對」、「受影響待修補」、「已修補待驗收」及「已驗收」，並保留判斷依據。這些是工作狀態，不能混成一個完成百分比。例如二十台設備中有十九台已更新，剩下一台若仍承接外部連線，其風險仍需要單獨說明。

交接摘要也應列出下一個明確動作、執行人和時間。遇到廠商支援等待、備份失敗或維護窗口不足，應留下具體阻礙與升級處理對象。如此下一班人員可以延續工作，而不必重新猜測哪些步驟已完成。

升級與事件判斷分別追蹤

CISA 的機器可讀目錄將本項的 forensicTriage 標為 Yes；勒索軟體活動欄位仍是 Unknown，不能據此宣稱已涉及勒索攻擊。目錄列有 10 月 16 日處置日期，組織應確認自身適用的規範與要求。[1]

實務上，修補證明與是否曾遭入侵的判斷應分別留存。有可疑活動時，交由事件應變人員依最新官方指引處理；不要用自行拼湊的指令或單一掃描陰性結果，替整台設備背書。交接時至少回答三個問題：還有哪些設備未確認、哪些修補尚未驗收、哪些事件調查仍未結案。

查核來源

[1] CISA 官方 KEV 機器可讀資料，目錄版本 2026.10.13，發布於 2026-10-13 19:10:43 UTC。

[2] Ivanti 提交的 CVE 官方紀錄及 CISA 補充資料，公開於 2026-10-13 15:31:07 UTC；CISA 補充欄位明確標示已遭實際利用。

[3] NCSC 2026 年 10 月 13 日公告。執行變更前另核對 Ivanti 原廠公告；本次無法直接取得該入口全文，因此分支修補表採 NCSC 公告。