重點摘要
- 2026 年 10 月 22 日 Synology 發布 PHP2Shell 公告 SA-26:14，Severity 寫 Critical、Status 寫 Resolved。Resolved 的意思是「廠商已針對公告範圍提供修補」，不是「你的 NAS 已經安裝」，也不是「已終止支援的版本都有修補」。
- 公告發布後修訂了兩次：10 月 26 日新增 Hyper Backup 條目，10 月 29 日補上 DSM 6.2、7.0、7.1。看公告要連修訂紀錄一起看。
- 看一則安全公告至少看四件事：受影響產品、修補版本、攻擊面、實際驗證。一則公告要算處理完，要有人確認影響、有人確認版本、有人修補、有人驗證、有紀錄。
- 10 月 29 日的勒索事件連入侵途徑都還沒有定論。廠商狀態與資產狀態是兩件事，中間那段是企業自己的責任。
做資安久了之後，我們越來越相信一句話：真正可以被相信的東西，應該是可以被驗證的。這不是不相信廠商，而是每次看到安全公告時提醒自己，公告上的狀態是廠商的狀態，我們的設備是另一回事。
2026 年 10 月 22 日，Synology 發布 PHP2Shell 的安全公告 SA-26:14。Severity：Critical。Status：Resolved。如果只看這兩格，很容易得到一個直覺：重大漏洞，已經解決。但我們認為不能停在這裡。
「Resolved」到底是誰的狀態？
廠商公告上的 Resolved，比較接近：針對這份公告界定的範圍，廠商已經提供處理方式。
受影響的版本也未必都拿得到修補。同一份 SA-26:14 裡，PHP 7.3 的嚴重性是 Critical，修補欄卻註明不會提供修補，原因是該版本已終止支援。Synology 另外在聲明中說明，DSM 本身內含一個供系統內部使用的 PHP 元件，官方評估風險極低，修補排入後續的 DSM 版本；DSM 7.2 以前的版本，官方建議先暫時停用受影響的套件。
所以 Resolved 不代表：你的 NAS 已經安裝；你的套件已經更新；已經停止支援的舊環境都有修補；你的整台設備不存在其他漏洞。
這不是文字遊戲，而是資安管理很重要的一條界線：廠商狀態（vendor status）跟資產狀態（asset status），是兩件事。 廠商說修好了，接下來才輪到我們確認：我們有沒有真的修好。
Synology 的公告本身也會變
SA-26:14 發布之後，修訂紀錄更新了兩次：
| 修訂 | 日期 | 內容 |
|---|---|---|
| 1 | 2026-10-22 | 初次發布 |
| 2 | 2026-10-26 | 新增 Hyper Backup 套件條目（標示不受影響） |
| 3 | 2026-10-29 | 新增 DSM 6.2、DSM 7.0、DSM 7.1 的更新資訊 |
Synology 的新聞稿也陸續把 PHP 安全更新延伸到已終止生命週期的 DSM 7.1、7.0 與 6.2。換句話說，同一個事件，在不同時間點能採取的處理方式可能不同；公告本來就會隨著調查更新。真正的風險只出現在一種情況：我們把某個時間點的公告，當成永遠不會改變的最終答案。所以除了狀態，我們也看公告的最後更新時間和修訂紀錄。
看 Synology 安全公告，至少看四件事
一、受影響產品：到底是哪個產品受影響？
「PHP 有漏洞」不等於「所有用到 PHP 的產品都能被攻擊」。系統裡存在某個舊元件，也不等於攻擊者一定走得到那段程式。元件在不在、攻擊路徑存不存在，要分開判斷。SA-26:14 列的是 PHP 套件、Calendar、Mail Station；Hyper Backup 後來被明確標示不受影響。
二、修補版本：要裝到哪一個完整版本？
只看「最新版」或大版號不夠，要對到公告列出的完整版本。例如 9 月的 SA-26:13，DSM 7.3 分支的修補版本是 7.3.2-86009 Update 4，7.2.2 分支是 72806-9，7.4 分支是 90075。差一個 Update 編號，就是有修與沒修的差別。
三、攻擊面：外部的人碰不碰得到？
即使套件受到影響，也還要問：需不需要登入？服務有沒有對網際網路開放？前面還有沒有其他隔離？碰不到的漏洞不是不用修，而是修補的急迫性不同，暫時修不了的也有緩解空間。
四、實際驗證：修補真的生效了嗎？
更新後實際跑的是不是新版？服務是否正常？紀錄裡有沒有異常？從外部掃描的結果，是不是跟我們以為的一樣？最後一步最麻煩，但也是「相信」真正開始有意義的地方。
10 月 29 日的 C3RB3R 勒索事件，為什麼讓這件事更明顯？
Synology 10 月 29 日表示，勒索軟體 C3RB3R（Cerber 家族的變種）正在利用一個 2024 年 12 月已經修補的弱點（SA-24:20，CVE-2024-10441），攻擊仍執行舊版 DSM 的設備。修補已經出來將近兩年，但只要設備沒有升級，對那台設備而言，漏洞從來沒有消失。
更值得注意的是，入侵途徑到目前為止並沒有定論。多家資安媒體引述奇虎 360 的分析，其調查的案例指向 9 月才修補的 CVE-2026-13639 與 CVE-2026-13684（SA-26:13）；另有事件應變團隊回報受害設備執行的是較新的 DSM 7.4.1，無法排除其他漏洞、套件或帳號遭濫用的可能。Synology 的聲明也沒有公布全球受害數量，或為每一起事件確認入侵路徑。
這正是公告有範圍、公告會變的實證。所以這件事不能簡化成「廠商已經修了，所以不是廠商的問題」，也不能簡化成「又有漏洞，所以產品不安全」。我們比較在意的是另一件事：一個組織有沒有能力知道自己有哪些設備、跑什麼版本，以及哪些修補還沒真正落地。這才是修補管理（Patch Management）真正困難的地方。
一則安全公告，怎樣才算處理完？
一封資安通知寄來，工程師看過，群組裡貼過，有人按了一個表情符號。這些都不能算處理完成。我們認為，一則安全公告要算處理完，至少要有：
- 有人確認影響範圍
- 有人確認實際版本
- 有人負責修補
- 有人驗證修補真的生效
- 必要時留下處理紀錄
- 暫時不能修的，知道目前用什麼方式降低風險
資安事件真正需要的，不是某個人很懂 CVE，而是一套收到資訊之後，能把資訊變成行動的流程。我們把這套流程的前半段（訂閱公告、比對資產、推播）交給 AI 工作流執行，後半段由人確認，做法見〈資安團隊如何靠 AI 工作流做到第一時間反應〉。至於「先修補、後通報」為什麼必須是制度而不是膽識，我們在〈重大漏洞先修補再報告，錯了嗎？〉分享過一次被客戶質疑的經驗。
這次我們自己的 Synology NAS 走完這六項的結果：10 月 22 日 SA-26:14 發布當天確認影響範圍，NAS 未安裝受影響的套件，DSM 版本 7.3.2-86009 Update 5 已高於 SA-26:13 的修補版本；10 月 29 日勒索聲明發布後再次核對版本與對外入口，確認沒有任何對外入口、僅能經 VPN 存取。處理紀錄依 ISO/IEC 27001 變更管理程序留存。
我們是不是不相信廠商？
不是。我們仍然高度依賴供應商：NAS 廠商要維護作業系統，Linux 發行版要維護套件，PHP、Node.js 這些上游專案要修漏洞。我們自己的產品也一樣，沒有任何現代軟體能完全脫離供應鏈。
所以問題不是「要不要相信廠商」，比較成熟的問題是：我們把多少信任交給廠商？又保留多少驗證能力在自己手上？廠商說 Not affected，我們希望知道它的判斷範圍。廠商說 Resolved，我們希望知道修補版本。設備顯示已是最新，我們還是要知道那個「最新」對應的是哪一個完整版本。這並非代表不信任，而是我們認為比較健康的信任應有的樣子。
介面上的「已更新」，只是第一層
Updated、Secure、Protected、Resolved，這些狀態很容易理解，也讓人安心。但企業資安麻煩的地方，在於這些字後面還有很多層：系統、套件、執行環境、帳號、網路、備份、監控，還有人。
這次事件給我們最大的提醒，不是某一個 CVE，而是：不要把「廠商已經處理」誤認成「我們已經處理」。中間剩下的那一段，就是企業自己的責任。NAS 被攻陷之後資料還在不在，是這段責任的最後一道防線，我們在〈NAS 備份架構：RAID、快照、不可變快照到離線備份〉說明。
常見問題
Synology 公告上的 Resolved 是什麼意思？ 代表 Synology 已針對該公告界定的產品與版本提供修補或處理方式。它不代表你的設備已安裝修補、不代表已終止支援的版本有修補，也不代表整台設備沒有其他漏洞。
怎麼知道我的 DSM 版本有沒有修補？ 到「控制台 → 資訊中心」看完整版本號（含 build number 與 Update 編號），對照公告列出的修補版本。例如 SA-26:13 要求 DSM 7.2.2 至 72806-9 以上。只看「已是最新版本」的提示不夠，因為它只比對你的機型目前能拿到的版本。
安全公告多久要重看一次？ 重大公告在發布後一到兩週內至少再看一次修訂紀錄。SA-26:14 在七天內修訂了兩次，內容包含新增受影響產品與補發舊版修補。
暫時無法更新的 NAS 該怎麼辦？ 依 Synology 建議，DSM 7.2 以前的版本先停用受影響的套件；同時把對外入口減到最少、確認離線備份完好。這些只是降低風險，不能取代更新。
修補管理和弱點掃描有什麼不同？ 修補管理是「知道該裝什麼、確認裝上了」的流程；弱點掃描是從外部或內部實際檢查「還有什麼碰得到」。兩者互補，掃描是驗證修補是否落地的方式之一。
想確認修補真的落地？
四件事裡最難的是最後一項「實際驗證」。影響視覺科技的影響資安提供弱點掃描與滲透測試，從外部實際檢查你的 NAS 與伺服器還有哪些入口碰得到；系統維運與資安監測則以每日自動健康檢查持續追蹤版本與服務狀態。想知道自己的設備現在是什麼狀態，歡迎預約諮詢。
這是「NAS 資安」系列的第 2 篇。第 1 篇：〈Synology NAS 勒索事件（2026 年 10 月）：企業第一件事不是問有沒有中〉；第 3 篇：〈NAS 備份架構〉。
本文整理時間：2026 年 10 月 30 日｜最後更新：2026 年 10 月 30 日