SonicWall 已公布 SMA1000 的修補版本。Previdian 隨後報告了符合 CVE-2026-102255 特徵的利用嘗試。對維護這類設備的團隊，我會把受影響且對外可達的設備排進緊急變更，同時開一張調查單。修補單確認正在執行的版本；調查單確認本地有哪些異常、哪些時段缺少紀錄。兩張單的結案依據不同。

這個判斷不需要先宣稱「大量企業已遭入侵」。已知受影響版本、可用修補與外部嘗試訊號，足以支持提高處理優先序；要判定自己的設備是否被控制，還需要自身環境的證據。

廠商聲明與蜜罐觀測，要保留各自的日期

SonicWall 產品公告標示初次發布為 2026 年 10 月 5 日、最後更新為 10 月 6 日。公告列出四項漏洞，其中 CVE-2026-102255 為 SSRF，CVSS 10.0；該版公告同時寫明，當時沒有這些漏洞遭在野利用的證據。

10 月 9 日出現了新的觀測。Previdian 的原始 LinkedIn 貼文使用「符合此漏洞的利用嘗試」這種有限度的措辭，並提醒公開的 IP 是調查指標，不能單獨證明入侵。它描述的是 WorkPlace 介面的未驗證 SSRF，攻擊者可能藉設備代送請求、碰到內部功能；本文不把這段描述延伸成已驗證的完整攻擊鏈。

Previdian 的 CVE 原頁在本次查核時顯示：

  • 24 次嘗試、1 個來源 IP、1 個感測器，信心等級為 Medium。
  • 首次與最後觀測日期皆為 10 月 9 日。
  • 時間線的 sensor observation 標為 10 月 9 日 00:33 UTC；來源收錄表的 Previdian Sensors 則列 08:49 UTC。兩欄記錄不同事件，不能把收錄時間直接寫成首次觀測時間。

這些是會更新的頁面數值，不是全球受害統計。24 次請求可能來自同一個來源反覆嘗試；1 個感測器也沒有提供推估全網攻擊規模所需的覆蓋範圍。10 月 6 日的廠商聲明不能抹去後來的觀測，後來的嘗試也不能倒推成廠商當時已確認成功入侵。

我會在事件單同時留下來源 URL、查核時間、原始措辭與觀測範圍。下一班值班人員才能知道「沒有證據」是哪一天、哪一個來源的說法，而非一個永遠有效的安全結論。

三種證據，分別支持三種工作

廠商公告可以支持版本比對與修補決策。蜜罐報告可以支持提高調查優先序。若要說某組織已遭入侵，則需要該環境的獨立證據，例如未授權的管理操作、設定變更或其他可核對的入侵跡象。

這項區分也符合 Previdian 的方法說明：其感測器所稱的 exploitation activity 包含利用嘗試，無論目標是否真的脆弱、嘗試是否成功。感測器衍生的 KEV 標記，不代表已證明特定組織遭入侵。Medium 是該服務對證據的分類，也不應轉寫成「已完全確認」。

工程上，我建議讓工單的狀態分開保存：

  • 資產適用性：型號及完整版本是否已核對。
  • 修補狀態：是否已安裝、是否確認執行中版本、服務是否通過驗收。
  • 調查狀態：有無異常線索、紀錄涵蓋哪段時間、哪些問題仍待確認。

這樣就能表達「修補完成，調查仍進行中」，也能表達「查無異常，但紀錄不完整」。單一綠色的「已處理」會把這些差異藏起來。

Threat Signals 的來源追溯設計討論了情報值、來源與判讀的關係。這次案例再加上一個要求：同一個 CVE 在不同日期可以有不同證據狀態，更新時應保留歷史，不要用新摘要蓋掉舊聲明。

盤點要讀完整 platform-hotfix，不能只看 12.4 或 12.5

依 SonicWall 的受影響與修補清單，本次範圍是 SMA1000 的 6210、7210 與 8200v，虛擬設備包含所有 hypervisor：

  • 12.4.3 分支：12.4.3-03526 及更舊版本受影響；修補版為 12.4.3-03670 及更高版本。
  • 12.5.0 分支：12.5.0-02952 及更舊版本受影響；修補版為 12.5.0-03082 及更高版本。

版本應按各自分支核對。資產表只寫「SMA」「VPN」或「12.5」時，資訊不足；其他 SonicWall 產品也不能因品牌相同就套用這份清單。

我的盤點清單會要求每台設備留下型號、用途、目前執行的完整 platform-hotfix、讀取時間、管理責任人，以及 WorkPlace 從哪些網路可達。若部署有備援節點或待命虛擬機，也逐台確認；只更新平常登入的那台，無法證明切換後仍在修補版本。

還要分開記錄管理介面與 WorkPlace 的可達性。限制管理介面有其價值，但從管理入口的設定，無法直接推論使用者入口的漏洞已被排除。這項盤點應依自己的網路規則與實際服務路徑完成，不能只相信一份過期的架構圖。

盤點停止規則：型號、執行中版本或實際服務節點仍有未知值時，該資產不能標記為已排除影響。 未知項目要有負責人及確認期限。

修補驗收要留下執行證據，也要保住合法連線

以下是我建議的變更清單，不是廠商提供的通用升級指令。每一步都只針對團隊有權管理的設備。

變更前，保留調查所需的紀錄

記錄當前版本、設定備份位置及必要的設備、認證與網路紀錄，註明各來源的時區和保存區間。備份與日誌可能含敏感資訊，應放在既有的受控位置。不要在工單附件公開貼上憑證、工作階段或使用者資料。

同時確認適用的升級路徑、維護窗口、連線中斷影響與復原安排。若暫時無法升級，列出阻礙、負責人、期限及經核准的暴露面限制。限制可達範圍可以降低風險；在沒有驗證前，工單仍要保留「未修補」狀態。

變更後，確認每台設備正在跑哪一版

保留設備管理介面或廠商支援方式讀到的完整版本，核對是否達到對應分支的修補版。下載檔名、安裝工作完成訊息與掃描工具的摘要，不能代替執行中版本的確認。

若有備援部署，依既有操作程序驗證各節點及切換後狀態。復原安排也要寫清楚：若退回已知受影響版本，修補狀態必須重新打開，並重新評估暴露面；服務恢復不代表安全變更已完成。

用既有帳號驗收正常流程與權限限制

確認合法使用者能登入、存取被授權的資源並正常登出；不具權限的測試帳號仍應被拒絕。檢查錯誤率、連線狀態與認證紀錄，記下測試時間及結果，方便和變更前比較。

這些檢查驗收的是營運行為，沒有證明漏洞重現測試已通過。若團隊沒有適合的隔離測試環境，也不應拿正式設備臨時跑來源不明的 exploit。可以延用 Django 安全更新的回歸驗收方式，將升級版本與應用行為分開留證。

IP 命中只會打開調查，不會自動完成判案

Previdian 的社群貼文提供了調查用 IP。實際使用時，應連同報告日期、來源與適用範圍保存，並核對自己看到的請求是否對應同一時間及服務。只有來源 IP 相同，還不知道請求內容、處理結果與後續行為。

我會把命中項目與設備、認證及網路紀錄串起來，確認是否接著出現無法解釋的管理操作、設定異動或內部連線。這是調查方向，不是本文宣稱該漏洞必然會留下的固定跡象。單一 IP 的有無命中，也不足以排除其他來源的嘗試。

調查停止規則：出現無法解釋的未授權行為，或關鍵紀錄缺失時，不以「已升級」結束事件評估。 有異常時交由既有事件應變流程處理；紀錄缺失則標明無法確認的期間與範圍。後續隔離、鑑識與復原由有權限的團隊決定，避免未留證就重建設備。

下一步是從資產清單選出所有 SMA1000，逐台補齊完整版本、對外可達路徑與負責人。把受影響設備送進有期限的修補變更，再為調查結果另留一欄。完成後，值班人員應能回答兩個具體問題：設備現在跑哪一版，以及對升級前的活動，我們知道多少。