NAS 收到漏洞警訊，怎麼看懂公告、確認版本與安排修補？

收到警訊後，先確認哪個程式有問題

收到 NAS 漏洞通知時，最有用的第一步是把通知和設備資料放在一起：公告提到哪個程式？我們有沒有安裝？版本是多少？哪些人連得到它？這幾個答案，會決定接下來要更新什麼、暫停哪些服務，以及如何驗收。

本文接續「NAS 已經斷網，接下來該確認什麼？」的共享與隔離觀念，進一步說明漏洞公告。以公開的 Synology DSM 與 PHP2Shell 公告作為教學例子，查核日為 2026-11-01；設備欄位由管理者實際填寫，本文不代填任何實驗室的修補或入侵結果。

先區分公告本身：SA-24:20 是 2024 年公布的 DSM 漏洞公告；SA-26:13 談 DSM；SA-26:14 談 PHP2Shell 與相關套件。收到新通知，不代表其中每個漏洞都是新發現。保留通知日期、公告編號與 CVE，再依實際適用條件判斷。

Synology SA-24:20 — DSM (PWN2OWN 2024)

CVE、CVSS、CWE：哪個是編號，哪個是評分？

CVE（Common Vulnerabilities and Exposures）提供公開漏洞的共同識別編號，讓廠商、管理者與研究人員指向同一個問題。看到 CVE 編號時，接著查看受影響產品與條件；編號本身不表示設備已遭入侵。

CVSS（Common Vulnerability Scoring System）描述漏洞的技術嚴重程度。公告中的 9.8 是評分，不是 98% 的入侵機率。判斷自己的風險，還要加入服務是否開放、版本、資料價值與現有控制。此處沿用公告標示的 CVSS3 分數，不將不同評分版本混用。

CWE（Common Weakness Enumeration）整理造成漏洞的缺陷類型；Security Advisory（SA）則是廠商公告，說明產品與修補資訊。一份 SA 可以列多個 CVE；同一類 CWE 也可能出現在不同產品。

CVE Program — About CVE Records

FIRST — CVSS v3.1 User Guide

MITRE — CWE-116

NAS 系統更新了，裡面的軟體也更新了嗎？

把 NAS 想成一台提供共同儲存空間的電腦：硬體承載作業系統，作業系統上再執行各種應用程式。DSM（DiskStation Manager）是 Synology 的作業系統；套件中心管理額外安裝的軟體。更新紀錄要分開留下，才能知道這次修補了哪個層次。

例如，某個研究網站需要 PHP 處理網頁請求；即使 DSM 已更新，仍應檢查網站所用 PHP 與相關套件。先列出實際安裝和啟用的功能，再對照公告；不需要為了核對一項漏洞，額外安裝原本沒有使用的套件。

Synology NAS User’s Guide for DSM 7.2, pp. 18, 25–26

Synology SA-26:14 — English

網頁裡的一次操作，如何交給後端處理？

你在網頁按下按鈕後，網頁服務會接收請求，再交給後端程式處理。SCGI（Simple Common Gateway Interface）是網頁伺服器與後端溝通的一種介面。可以把它想成櫃檯傳遞表單：表單內容要按雙方約定的格式處理，才能保留原來的意思。

編碼與跳脫處理，是讓資料在特定格式中被正確理解的方法。例如，一段一般文字裡的特殊符號，需要依輸出情境處理，避免被當成格式結構。這個比喻說明 CWE-116 的類型，不提供或推測實際攻擊字串。

SA-26:13 將 CVE-2026-13684 歸為 SCGI 輸出處理缺陷；可能影響檔案讀寫與服務可用性。處理方向是比對 DSM 修補版本，並管理哪些路徑能接觸服務。

MITRE — CWE-116

Synology SA-26:13 — DSM

安全通行證為什麼要讓人猜不出來？

有些安全機制會產生暫時使用的值，用來區分請求或驗證身分。若產生規則容易被推測，原本應只有特定人知道的值，就可能被猜到。這裡的熵（entropy）用來討論不可預測性；字串看起來亂，並不等於產生方式足夠安全。

圖中的數字與字母是教學例子。真正的安全設計還要考慮產生器、長度、保密方式、有效時間與伺服器驗證。不能從三個範例字串推算真實系統的熵。

CVE-2026-13639 被歸為 DSM 登入邏輯的 CWE-331 隨機性不足。此處用通行證解釋概念，沒有將它斷言成猜密碼或特定 Session ID 的問題。

MITRE — CWE-331

Synology SA-26:13 — DSM

程式用完記憶體後，為什麼還可能出錯？

PHP 是常用於網站後端的程式語言。程式處理請求時會取得記憶體空間、放入資料，再於適當時機釋放。若中途遇到記憶體不足（Out of Memory，OOM），也需要把尚未完成的狀態清理好。

PHP2Shell 的兩項公告描述不同問題：CVE-2026-109618 涉及 OOM 提早離開流程後留下無效或未完成初始化的請求記憶體；CVE-2026-109619 涉及全域狀態仍指向已釋放的請求記憶體。後續流程再使用這些狀態，就可能出現不安全行為。

遠端程式碼執行（Remote Code Execution，RCE）表示攻擊者可能讓受影響程式執行非預期程式碼。影響範圍還取決於執行身分、系統權限及隔離控制。圖解用來理解狀態管理，實際處理仍以相容的修補套件與驗收為主。

PHP — RCE via OOM corruption

PHP — RCE via stale global state

要更新到哪個版本，怎麼確認？

先記下機型、DSM 完整版本與 Update 編號，再看公告相同版本系列的修補門檻。完整版本要保留尾碼；不要只記「7.4」或以字串大小比較兩個不同分支。升級路徑與相容性依機型官方資訊確認。

下表是 SA-26:13 的修補門檻，不是本文宣稱的最新版本。設備是否已修補，需拿實際畫面與公告對照；這份版本紀錄也不能取代異常登入或檔案變更的事件調查。

Synology SA-26:13 — DSM

套件中心還要確認哪些版本？

先列出實際安裝的套件及完整版本，再對照下表。表內 PHP 7.4、PHP 8.0、Calendar 與 Mail Station 的門檻採 DSM 7.2 以上欄位；較舊 DSM 必須查公告對應分支。PHP 7.3 已停止支援，應先確認相依功能，再安排遷移或停用。

2026-11-01 查核時，SA-26:14 英文頁標示更新於 10/29，波蘭語頁標示 10/31，後者補上舊 DSM 的套件門檻。兩頁表格均將 Hyper Backup 列為 Not affected，範圍限這份公告的漏洞。採用前重新查看產品表與日期；一般備份可用性仍以還原測試確認。

Synology SA-26:14 — English

Synology SA-26:14 — Polish locale, expanded version table

NAS 暫停外網連線後，更新檔怎麼送進去？

先確認維護窗口、可信備份與目前是否需要保留事件證據。若有入侵疑慮，先由事件處理人員判斷蒐證與修補順序；更新程式與清除入侵者的活動，是不同工作。

離線更新的做法，是先在可信下載環境取得相容檔案，再以受控方式移入隔離管理網路。DSM 更新檔通常為 .pat，套件為 .spk。逐一核對官方來源、機型、版本、相依項目，以及廠商提供的完整性驗證資訊。隔離管理電腦不應同時橋接外網。

官方 DSM 7.2 使用手冊第 18、25–26 頁示範套件中心的手動安裝及控制台「更新與還原」的手動更新。實際選單和可用路徑依目前 DSM 與機型核對。安排服務中斷時間，更新時維持供電，完成後重新登入、核對版本與必要功能。

先用測試資料夾及可丟棄的測試檔確認讀寫，再逐項恢復服務。保留更新前後版本、操作時間與結果；還原測試和帳號權限測試也各自留下證據。

Synology NAS User’s Guide for DSM 7.2, pp. 18, 25–26

入口有身分檢查，為什麼程式還要修補？

入口防護決定哪些人可以接近服務，程式修補則處理服務本身的缺陷。以 Cloudflare Tunnel 為例，內網連接器建立對外通道；身分允許規則需另外設定。NAS 的帳號與資料夾權限也繼續生效。

就像大樓櫃檯會確認訪客身分，室內設備仍需要維修。獲准使用者、遭竊帳號或內網電腦仍可能接觸後端。驗收時分別測試通道、身分規則、服務版本與檔案權限；網頁入口和 SMB 路徑也各自確認。

Cloudflare Tunnel

更新完成後，要留下哪些確認結果？

把工作收斂成五份簡短紀錄。每項都填入查核時間、負責人及可重現的結果；缺資料時寫清楚下一步要取得什麼。這是一份管理者使用的工作表，不是網站自動掃描結果。

先理解共享與隔離，可接著閱讀前篇 NAS 觀點。兩篇合起來，從日常使用走到公告判讀，再走到修補驗收。

• DSM：完整版本、Build、Update、對應公告與比對結果。
• 套件：已安裝／啟用項目、完整版本、相依功能與處理結果。
• 異常紀錄：登入、帳號、服務與檔案變更的查核範圍；疑似事件的承接人。
• 網路入口：授權與未授權連線結果、網頁／SMB 路徑及資料夾權限。
• 復原：獨立備份位置、版本保留及實際還原測試結果。

用一個例子，確認你能做出判斷

紙上情境：一台 NAS 的 DSM 已符合對應公告門檻，但套件中心的 PHP 8.2 完整版本尚未取得，且一個已啟用的網站需要 PHP。請先列出還缺哪些資訊，再回答以下問題。此練習只需閱讀與記錄，不執行漏洞利用或更動設備。

對照思路：DSM 與 PHP 分別核對；先取得套件完整版本、相依服務與可達路徑。隔離能控制接觸機會，修補則處理缺陷。通道可用也只是驗收的一部分，仍需版本、身分、權限與復原證據。

• DSM 已更新，能否推定 PHP 也修補完成？要查看什麼？
• 阻斷外網後，哪些內網路徑仍值得確認？
• 準備恢復服務前，你會如何證明有權限的操作成功、無權限的操作被拒絕？