先說結論：管理 Fortinet FortiOS 或 FortiSwitchManager 的單位應查核 CVE-2025-25249。Fortinet 的 FG-IR-25-084 說明，這是 cw_acd 元件中的堆積區緩衝區溢位；cw_acd 是設備內協助相關管理通訊的背景程序。弱點可能讓未經登入的遠端行為者在符合條件的環境中執行非預期程式，但原廠也指出既有記憶體防護會提高利用難度。CISA 於 2026 年 9 月 9 日把此 CVE 加入已知遭利用漏洞目錄（KEV），因此不能只看原廠較早公告中『未標記為已知利用』的欄位。應按產品分支確認修補版本、縮小不必要的 Fabric 管理通訊曝露面，並驗證升級已生效。本文在 10 月 4 日重新查核兩個官方來源，不把漏洞收錄直接寫成讀者設備已遭入侵。
背景與前因：Fortinet 的原廠公告於 2026 年 1 月 13 日首次發布，並在 1 月、2 月補充內容與修正版本表；CISA 的 KEV 收錄日期則是 9 月 9 日。這不是同一天重複的兩則新聞。原廠公告較早描述產品本身與修補方式，CISA 後來提供另一個與實際利用有關的優先處置訊號。KEV 是美國主管機關用來標示已知遭利用漏洞的公開清單，幫助維運單位排序工作；被加入清單不代表任何特定組織的設備一定已受害。本文是一篇補刊，原始公告日期、CISA 收錄日期和本次查核日期都應分開看，不以補刊發表時間製造『今天才發現漏洞』的印象。
原因與前置條件：堆積區是程式在執行時配置資料的記憶體區域，緩衝區溢位可白話理解為資料超出原本預留的界線，導致程式處理狀態失去預期。Fortinet 說此問題存在於 FortiOS 與 FortiSwitchManager 的 cw_acd 背景程序，特定請求可能造成執行未授權程式的風險。原廠同時指出 ASLR 與 PIE 等記憶體防護會明顯增加利用所需的準備和複雜度；這些縮寫指作業系統與程式對記憶體位置安排的防護設計。它們能提高攻擊難度，不等於漏洞不存在，也不能替代修補。本文不提供構造請求或繞過防護的做法，因為維運決策只需確認產品、版本及服務曝露面。
影響範圍：Fortinet 的版本表將 FortiOS 7.6.0 至 7.6.3、7.4.0 至 7.4.8、7.2.0 至 7.2.11、7.0.0 至 7.0.17 列為受影響，對應的修補基準依序為 7.6.4、7.4.9、7.2.12、7.0.18 或以上。FortiOS 6.4 分支在原廠表中要求遷移到已修補發行版，不能把某個舊版號誤當成安全終點。FortiSwitchManager 7.2.0 至 7.2.6、7.0.0 至 7.0.5 受影響，修補基準分別是 7.2.7 與 7.0.6。這些數字是原廠針對此 CVE 的公告版本，不保證在 10 月或未來就是產品的最新版本，升級路徑仍應以原廠當時可用資訊確認。
盤點時不要把 Fortinet 品牌下所有產品混成一張表。應逐台確認是 FortiOS 還是 FortiSwitchManager，記下實際分支、版本、設備角色、網路位置和管理責任人。若同一環境有多台高可用性設備或備援節點，需分別檢查；僅看到主節點版本更新，不足以證明備援節點也完成修補。對已退役但仍通電、仍可連接管理網路的設備，也要核對狀態。CISA 的 KEV 目錄用產品名稱和 CVE 提供優先順序，卻不會替讀者列出現場資產。缺少盤點資料時，不能宣稱全網已修補，也不應據此推斷所有未列名型號都受影響。
兩個來源的利用狀態欄位看似不同，原因在時間。Fortinet 較早發布、最後於 2 月更新的 FG-IR-25-084 頁面標示 Known Exploited 為 No；CISA 在 9 月 9 日把同一 CVE 加入 KEV。前者是原廠頁面截至較早更新時點的標記，後者是後來的政府清單判斷，不能用舊欄位否定新收錄。另一方面，CISA 的目錄也沒有在此條目給出本文讀者設備的鑑識紀錄、受害者清單或攻擊成功率。最穩妥的說法是：官方已將漏洞列入已知遭利用的優先處置範圍，而個別設備是否遭利用仍須靠本地紀錄調查。
你可以怎麼做：先盤點所有相關設備的分支與版本，再按照 Fortinet 原廠列出的修補基準和官方升級路徑安排更新。網路安全設備往往承擔連線、策略或管理功能，變更前應保留設定、確認相容性、安排可回復窗口，並把高可用性節點的更新順序寫清楚。升級後從設備本身讀取實際版本，檢查重要服務、管理連線與策略運作是否正常；不要把下載韌體、上傳檔案或派送任務等同於完成安裝。若系統由外部服務商管理，應要求回覆具體版本與驗證紀錄，而不是只取得『已處理』的簡短回報。
Fortinet 也提出暫時性的曝露面控制方向，重點是限制不必要的 Fabric 相關服務存取。Fabric 可理解為設備之間協同管理與分享安全資訊的功能集合；若某些介面不需要相關管理通訊，應按原廠與現場網路設計檢討是否關閉或限制。這是等待更新期間降低風險的措施，不能等同於裝上修補版本。管理者應先確認相關服務是否支撐既有管理流程，再依正式變更程序操作，避免因單純套用他人設定而中斷安全設備互通。本文不提供可直接複製的設備命令或封包條件。
對於無法在同一窗口升級的設備，應將例外清單與曝露面控制、負責人、預定完成日期連在一起，並追蹤是否有人長期把『暫時』措施當作永久修補。若監控發現管理程序異常、設備設定突然變更或連線模式不符合平常狀態，應保存紀錄並依組織的事件應變流程分析。這些異常需要獨立證據，不能只因設備版本落後就宣稱遭入侵；反過來說，沒有告警也不構成絕對安全保證。優先更新的理由來自已知利用訊號與原廠修補資訊，而非臆測單一設備的攻擊過程。
未解問題包括各組織實際有多少受影響設備、哪些介面啟用相關服務、網路上是否有不必要的管理曝露，以及修補後哪些節點仍需驗證。Fortinet 與 CISA 的公開資料無法替現場回答這些問題。將產品、版本、位置、曝露面、變更窗口、完成後版本與例外原因寫入同一追蹤紀錄，才能在多分支與多節點環境中看出進展。後續若原廠修訂受影響範圍、CISA 更新清單或現場發現新的事實，應同步修正文稿與維運清單，而不是固定沿用 1 月或 9 月的單一快照。
這篇補刊依 Fortinet FG-IR-25-084 原廠公告與 CISA 官方 KEV 目錄整理，10 月 4 日重新查核兩個官方來源。已確認的行動是對照受影響分支升級、在必要時降低 Fabric 服務曝露面並核對實際版本。原廠舊頁面的利用標記與後來 CISA 收錄日期必須保留時間脈絡；兩者都不能單獨證明任何讀者的設備已遭控制。把這個差異說清楚，有助於維運團隊依最新優先訊號處理，同時避免誇大現場未經證實的損害。
官方來源：
- FG-IR-25-084: Heap-based buffer overflow in cw_acd daemon（Fortinet）
- Known Exploited Vulnerabilities Catalog — CVE-2025-25249（CISA）
這篇觀察對你有幫助嗎？
支持 Darknoted 持續維護隔離研究環境、資料查核與內容更新。
了解如何支持本站更新紀錄
：完成公開內容與 metadata 更新。