CISA 新增兩項已知遭利用漏洞：企業應把 KEV 納入曝露面與修補決策

CISA 於 2026 年 7 月 27 日公告，將兩項具「已遭主動利用」證據的漏洞新增至 Known Exploited Vulnerabilities（KEV）Catalog：CVE-2025-68686，以及公告中列示為 Arista VeloCloud Orchestrator On-Prem 的 CVE-2026-16812。對企業維運團隊而言，這不是又一份可延後處理的漏洞清單；KEV 的意義在於，CISA 已掌握漏洞遭利用的證據，應立即進入資產盤點、風險排序與修補決策流程。

但「立即處理」不等於在所有環境直接套用更新。網路與邊界設備通常承接遠端存取、身分驗證、站點互連、管理介面與既有整合，修補工作必須同時處理曝露面、設定依賴、維運窗口與修補前的鑑識需求。尤其對跨據點、混合雲與 Apple 裝置併存的企業，真正需要建立的是可持續運作的漏洞管理閉環，而非一次性的版本追趕。

本次 KEV 公告確認了什麼

依 CISA 公告，新增項目包含 CVE-2025-68686，描述為 Fortinet FortiOS 的未授權敏感資訊曝露漏洞；另一項為 CVE-2026-16812，公告描述為 Arista VeloCloud Orchestrator On-Prem 的作業系統命令注入漏洞。CISA 指出，這類漏洞是惡意行為者常見的攻擊途徑，對企業環境構成顯著風險。

需要注意的是，這份公告的功能是通知 KEV Catalog 的異動，不是完整技術通報。公告內容並未提供受影響版本範圍、利用鏈、入侵指標、修補版本、替代緩解措施或實際受害情境。因此，企業不能僅依漏洞名稱判定是否受影響，也不應將公告中的產品描述直接視為自身環境的資產對應結果。

實務上，應以內部 CMDB、網路設備管理平台、採購與維護合約資料、組態備份及外部曝露掃描結果交叉確認。若資產名稱、供應商歸屬或部署模式與公告描述不一致，應回到對應 CVE 記錄與原廠安全公告確認，而不是基於關鍵字比對貿然變更。這一步可避免將不相關設備納入緊急維護，也能降低真正受影響資產因命名不一致而被遺漏的風險。

先判斷是否可被利用，而不是只看 CVE 編號

KEV 排序的第一個問題不是「漏洞嚴重度多少」，而是「這項資產是否存在、是否曝露、是否可被攻擊者到達」。對網路作業系統、集中管理平台與編排系統而言，至少應確認四件事：設備或平台是否仍在用、實際軟體與版本為何、管理或服務介面是否對網際網路或不受信任網段開放，以及該系統掌握何種權限與連線範圍。

若受影響元件位於公開可達的管理平面，或可透過 VPN、跳板主機、合作夥伴網路等路徑存取，風險應高於只存在於隔離測試網段的相同版本。反之，即使設備未直接對外，也不能將它視為零風險；內部橫向移動、既有帳號遭濫用，以及管理網段分段不足，都可能讓攻擊路徑成立。

此外，企業應把「取得控制後的影響」與「目前的補償控制」分開評估。例如，平台若持有網路組態、站點憑證、管理帳密或自動化部署權限，遭入侵後的影響可能延伸至多個據點。多因素驗證、來源 IP 限制、獨立管理網段與最小權限，未必能取代修補，但可作為修補前後降低可利用性的控制措施。這些措施是否已確實啟用，應以設定與日誌驗證，而非以政策文件推定。

修補前先保留調查能力

CISA 在公告中提到，BOD 26-04 對美國聯邦文官行政部門機關建立以風險為基礎的更新優先順序，並對部分高風險情境提出修補前檢查是否已遭入侵的基本期待。該指令的強制適用對象是 FCEB 機關，並不直接約束臺灣或一般民間企業；然而，其中「先確認是否已受害，再完成修補」的原則值得納入企業流程。

原因很直接：修補可以阻斷已知入口，卻不會自動移除既有後門、竊取的憑證或已被修改的設定。若團隊在未保留必要證據前立即覆寫版本、重啟服務或清除記錄，後續可能難以判斷攻擊是否已發生，以及影響範圍是否跨越單一設備。

在不延誤高風險處置的前提下，可由資安、網路與維運共同決定最小化的保全範圍：保存管理平台與設備的登入、管理操作、設定異動、系統事件與網路連線紀錄；記錄目前版本、組態雜湊或備份時間點；盤點近期新增的管理帳號、權限調整與異常遠端來源。公告並未提供本次兩項漏洞的特定入侵指標，因此，調查應以環境基線、異常行為與原廠後續指引為準，不能把一般性檢查當成已確認的偵測規則。

更新部署的取捨：可回復性比速度更重要

對承擔核心連線的設備而言，緊急修補仍須具備可回復性。團隊應先確認支援的目標版本與升級路徑、組態備份是否可還原、憑證與身分整合是否有相依性，以及是否需要同步升級管理端、節點端或高可用成員。這不是為了放慢修補，而是避免在高壓事件中因版本不相容、組態轉換或叢集狀態異常，額外造成服務中斷。

建議把作業切分為明確階段：先建立受影響資產清單與對外曝露狀態；再依可利用性與業務影響排定維護窗口；於變更前完成設定與日誌保全；在受控範圍驗證升級路徑；最後於正式環境確認版本、管理平面可用性、站點連線、監控告警與備份作業均正常。每一步都應保留負責人、完成時間、證據位置與例外原因，讓後續稽核與下一次事件處置有可追溯基礎。

對 Apple 平台與其他終端裝置管理而言，這次公告未指出 iOS、macOS 或 Apple 裝置本身受影響。不過，若企業以網路閘道、遠端存取服務或集中編排平台承接 Apple 裝置的企業連線，仍應確認修補期間的裝置註冊、憑證更新、VPN 存取與管理服務是否受到影響。把「裝置沒有 CVE」誤解為「使用者服務沒有風險」，是跨平台維運中常見的判斷落差。

把 KEV 轉成可持續的治理訊號

KEV Catalog 不應只是資安團隊手動查閱的外部網站，而應成為漏洞治理中的優先排序輸入。成熟的做法不是把所有 CVE 一律升為最高優先，而是將 KEV 狀態與企業自身的資產重要性、網路可達性、權限範圍、補償控制、修補可行性及已知異常事件共同判讀。

這也代表資料品質是漏洞管理的前提。若企業無法回答「誰擁有這台設備」「它是否對外」「它正在跑哪個版本」「哪個服務依賴它」「最近一次備份與變更何時完成」，即使收到 KEV 通知，也難以在合理時間內採取正確行動。長期維運應優先補齊資產識別、組態管理、集中日誌與變更紀錄，而不是只增加更多掃描報表。

本次公告可支持的結論很明確：兩項新增 CVE 已因主動利用證據而列入 CISA KEV Catalog，相關組織應優先確認是否存在且可被利用的資產，並在保留必要調查能力後儘速依原廠與環境條件完成緩解或修補。至於特定版本、利用方式與偵測特徵，現有來源未提供足夠資訊，應等待並查核對應 CVE 與原廠安全文件後再做技術定論。