重點摘要
- 2026 年 10 月 29 日，Synology 發布聲明：勒索軟體 C3RB3R 正在攻擊仍執行舊版 DSM 的 NAS，利用的是 2024 年 12 月就已修補的漏洞（SA-24:20，CVE-2024-10441）。修補早就有了，攻擊卻現在才發生。
- 同一個月，Synology 還有兩份 Critical 公告：9 月的 DSM 漏洞 SA-26:13，與 10 月 22 日的 PHP2Shell 公告 SA-26:14。公告上的「Resolved」只代表廠商已提供修補，不代表你的那台 NAS 已經裝上。
- 我們公司內部也使用 Synology NAS，依下文的五個問題在當天完成盤點、更新與驗證，實際狀況寫在第六節。
- 本文附事件時間軸與 IT 管理者檢查表。企業真正要回答的問題只有一個：公司能不能承受一台 NAS 被攻陷。
Synology NAS 勒索事件時間軸：2026 年 9 月到 10 月發生了什麼？
這次不是單一事件，而是一個月內接連發生的四件事。把時間排開，才看得出「修補」與「攻擊」之間的落差。
| 日期 | 事件 | 對企業的意義 |
|---|---|---|
| 2024 年 12 月 | Synology 發布 SA-24:20，修補 CVE-2024-10441（CVSS 9.8，遠端執行程式碼） | 這就是 10 個月後被勒索軟體利用的漏洞 |
| 2026 年 9 月 18 日 | Synology 發布 SA-26:13，DSM 多個漏洞，最嚴重的 CVE-2026-13639 CVSS 9.8；修補版本 DSM 7.3.2-86009-4、7.2.2-72806-9、7.4-90075 | 版本要對到完整 build number，不是「7.2 就好」 |
| 2026 年 10 月 21 日 | PHP 與 Node.js 上游同日發布重大安全更新 | 我們當晚修補了 25 個自家維運的專案，見〈PHP2Shell 與 Node.js 高風險漏洞同日爆發〉 |
| 2026 年 10 月 22 日 | Synology 發布 SA-26:14（PHP2Shell），Critical；PHP 7.3 因已終止支援不提供修補 | NAS 上的 PHP 套件、Calendar、Mail Station 要另外核對版本 |
| 2026 年 10 月 26 日 | SA-26:14 修訂：新增 Hyper Backup 條目，標示不受影響 | 公告會變，要看修訂紀錄 |
| 2026 年 10 月 29 日 | SA-26:14 再修訂：補上 DSM 6.2、7.0、7.1 的更新資訊；同日 Synology 發布勒索聲明，呼籲立即更新 DSM 並開啟自動更新 | 已終止支援的版本也拿到修補，代表廠商判斷風險夠高 |
修補與攻擊之間隔了將近兩年。對企業來說，這代表「廠商已經修補」和「我們的設備已經安全」之間，隔著一段需要有人負責的距離。以下是我們用來檢查這段距離的五個問題。
一、這台 NAS 由誰負責？現在跑的是什麼版本？
很多公司的 NAS，是某一年某個同事架起來的，之後就一直在角落運作。出事的時候，最先卡住的往往不是技術，而是沒有人能立刻回答：
- 這台 NAS 由誰負責？
- DSM 是哪一個完整版本？
- 裝了哪些套件，哪些已經沒有人在用？
- 哪些服務對外開放，當初是為了什麼？
版本要看到完整的 build number，再對照官方公告列出的修補門檻。以 SA-26:13 為例，DSM 7.2.2 要到 72806-9 以上才算修補；SA-26:14 則要另外核對 PHP 與相關套件的版本。公告上寫「Resolved」，只代表廠商已經提供修補，不代表公司裡的那一台已經裝上。
二、NAS 的哪些入口真的需要對外？
我們接著看的是攻擊面，而不是漏洞清單。遠端管理、檔案分享、Web Station、SSH，每一個功能都有存在的理由，但企業要問的是：這個入口現在還有業務需要嗎？
我們的檢查方式是從外部看自己：
- 從公司網路外面，哪些連接埠和網址連得到？
- 哪些管理功能真的需要遠端使用？能不能改走 VPN 或其他受控入口？
- 對外的網站、Git、容器服務，能不能移到跟存放資料的 NAS 分開的主機？
最好的修補，有時候不是等 patch，而是讓攻擊者根本碰不到那個入口。
三、DSM 更新之後，誰確認它真的生效了？
我們不把「按下更新」當成完成。更新之後，要有人確認服務重新啟動、實際執行的是新版本、功能正常、對外入口沒有改變，並回頭看更新前的紀錄有沒有異常。
一次更新能涵蓋的範圍也有限。兩個例子：
- Synology 在 PHP2Shell 的聲明中說明，DSM 本身也內含一個供系統內部使用的 PHP 元件，官方評估風險極低，修補排入後續的 DSM 版本。也就是說，套件更新完，DSM 核心的那一份要等下一版。
- 10 月 30 日的第三方實測發現，Synology 的 Node.js 套件更新確實帶進了上游修補，但同一台 NAS 上其他服務用的是另一個版本，DSM 內建的版本也不會跟著套件更新。
這不代表那些元件一定有可利用的漏洞，但企業需要知道一次更新的邊界在哪裡。從看到公告到確認修補落地，中間該有哪些步驟，我們在〈Synology 公告寫 Resolved，你的 NAS 就安全了嗎？〉有完整整理。
四、NAS 被拿下之後，備份還在嗎？
這是我們最在意的問題。如果正式資料、快照和備份硬碟都在同一台 NAS 上，或一直接著它，攻擊者只要拿到這台 NAS 的管理權限，就可能一次處理掉全部。
我們的標準是：至少一份備份平時不跟 NAS 連在一起；能用不可變機制的地方就用（Synology 在支援的機型上提供不可變快照）；而且要定期做還原演練，記錄還原要多久、最多會遺失多少時間的資料。
怎麼一層一層設計，讓資料不會跟 NAS 一起出事，我們在〈NAS 備份架構：RAID、快照、不可變快照到離線備份〉詳細說明。
五、為什麼 MFA 不能取代前面四件事？
強密碼、減少管理員帳號、開啟 MFA、監控異常登入，這些都要做。但它們防的是「有人猜到或偷到密碼」。如果攻擊利用的是不需要驗證就能遠端存取的漏洞，攻擊者根本不必知道密碼。
所以帳號安全不能取代更新、入口管理和備份。每一項都可能失敗，企業要設計的是：任何一項失敗時，資料都還有退路。
六、我們自己的 Synology NAS 這次怎麼處理？
我們公司內部也使用 Synology，NAS 裡放的是工作資料，所以這五個問題我們先對自己問了一遍。與 10 月 21 日的 PHP／Node.js 事件一樣，我們是從官方公告第一時間得知，當天完成內部設備的檢查與更新。
| 項目 | 結果 |
|---|---|
| 盤點 | 公司內 1 台 Synology NAS，有指定負責人與清冊，仍在原廠支援期內 |
| 版本 | DSM 7.3.2-86009 Update 5，高於 SA-26:13 要求的 7.3.2-86009 Update 4 |
| 對外入口 | 沒有任何對外入口：未啟用 QuickConnect、未綁定 Synology 帳戶、沒有連接埠轉發，所有存取一律先連公司 VPN 進內網才能到達 NAS |
| 驗證 | 更新後確認實際執行版本與服務正常；並從外部確認無法直接連線 |
| 備份 | 離線備份最近一次成功於 10 月 29 日晚間，異地備份為每日排程；還原演練耗時與結果見第 3 篇 |
這台 NAS 不需要在這次事件中「緊急修補」，因為它平時就維持在修補版本上，而且攻擊者從外部碰不到它。寫出這些的目的不是展示，而是示範「處理完成」長什麼樣：每一列都有人確認過，不是看到公告就算。
企業真正要回答的問題：能不能承受一台 NAS 被攻陷？
表面上，這是一起 Synology 的資安事件。但企業真正要重新檢查的，是公司能不能承受一台 NAS 被攻陷。
如果答案是「NAS 出事，公司就沒有資料」，那問題就不只是哪個廠商有沒有漏洞，而是我們把太多信任放在一台設備上。任何設備都會有漏洞，任何更新都可能晚到，任何管理員都可能漏掉一次。我們能做的，是讓這些事情發生時，公司還有下一步：即使最壞的情況發生，公司仍然有一份攻擊者拿不走、而且確定還原得回來的資料。
給 IT 管理者的 NAS 資安檢查表
以下是建議的盤點頻率，請依自己的風險調整；出現重大安全公告或已知被利用的漏洞時，不必等到排定的時間，應該立即評估。
| 項目 | 怎麼檢查、怎麼算完成 | 建議頻率 |
|---|---|---|
| 負責人與清冊 | 每台 NAS 有指定負責人；清冊記錄機型、完整版本、已安裝套件、是否仍在原廠支援期內 | 每季 |
| 實際版本 | 對照原廠公告的修補門檻與版本說明，記錄版本與差距 | 每月；重大公告時立即 |
| 對外入口 | 從外部測試對外 IP、遠端網址、反向代理入口；記錄預期與實際結果 | 每季，以及網路設定變更後 |
| 對外服務 | 網站、Git、容器等服務不放在存放資料的 NAS 上 | 每季 |
| 帳號權限 | 管理員人數、預設帳號、兩步驟驗證 | 每季 |
| 快照 | 重要資料夾都有排程；依機型確認不可變快照與保留設定 | 每月；快照失敗時立即告警 |
| 離線與異地備份 | 還原演練，記錄還原耗時與可接受的資料遺失時間 | 每季 |
| 日誌與告警 | 異常登入、大量檔案變動有人收到、有人追查；定期測試告警送得到 | 每月測試 |
| 應變流程 | 斷網隔離、保留現場、通知誰、找誰協助，演練一次 | 每年 |
常見問題
Synology NAS 還安全嗎？ 這不是有用的問題。任何持續開發、有網頁管理介面、連著網路的 NAS 都會有漏洞。有用的問題是：你的 NAS 是否在原廠支援期內、是否更新到公告列出的修補版本、對外入口是否只剩必要的，以及 NAS 被攻陷時資料能否從別處還原。
DSM 要更新到哪一版才算修補？ 以 SA-26:13 為例，DSM 7.3 要到 7.3.2-86009-4、7.2.2 要到 72806-9、7.4 要到 90075 以上。請對照 Synology 公告的完整 build number，不要只看大版號。PHP2Shell（SA-26:14）另外要核對 PHP、Calendar、Mail Station 等套件版本。
已經更新到最新版，還會被 C3RB3R 勒索嗎？ 依 Synology 10 月 29 日的聲明，攻擊鎖定的是仍執行舊版 DSM 的設備。但入侵途徑仍有不同分析，詳見本系列第 2 篇。更新是必要條件，不是充分條件；對外入口管理與離線備份同樣重要。
NAS 疑似被勒索，第一步該做什麼？ 先斷網隔離，不要重開機或刪除任何檔案，保留現場；確認離線或異地備份是否完好；再通知負責人與資安協助單位。不要急著付贖金或自行清除，那會破壞還原與鑑識的依據。
只開啟 MFA 和強密碼夠嗎？ 不夠。MFA 防的是密碼被猜到或偷到；這次被利用的是不需要驗證的遠端漏洞，攻擊者不必知道密碼。更新、入口管理、備份與帳號安全缺一不可。
需要有人替你盯著 NAS 與伺服器嗎？
檢查表上的每一項都需要「有人收到、有人確認」。如果公司沒有專職資安人力，影響視覺科技的 AI 網站暨系統資安監控通報平台可以 7×24 監測伺服器與系統異常，由 AI 判讀嚴重度，以 LINE 或 Email 分級通報並附應變步驟；影響資安則提供維運監測、備份與災難復原的建置協助。不確定自己的 NAS 現況，歡迎預約諮詢。
這是「NAS 資安」系列的第 1 篇。系列另外兩篇：〈Synology 公告寫 Resolved，你的 NAS 就安全了嗎？〉、〈NAS 備份架構：RAID、快照、不可變快照到離線備份〉。
本文整理時間：2026 年 10 月 30 日｜最後更新：2026 年 10 月 30 日