個人觀查分享:從 10 月這波 Synology 勒索事件，聊聊資安公告上的「Resolved」到底代表什麼

這幾天 Synology NAS 的資安消息一個接一個：DSM 漏洞、PHP2Shell、C3RB3R 勒索，還有 Node.js 套件更新。
消息混在一起之後，很容易變成兩種極端說法：
一種是「Synology 被破解了，不安全」；
另一種是「漏洞早就 Resolved 了，是使用者自己沒更新」。


個人認為兩種都過度簡化。以下整理截至 2026/10/30 可以確認的公開資訊，順便留一份當下的紀錄，有誤請各位指正。

【1. 9/18：DSM 本身的 Critical 漏洞】
Synology-SA-26:13 在 2026/9/18 公開。其中值得注意的兩個：
・CVE-2026-13639：DSM 登入邏輯的亂數熵不足
・CVE-2026-13684：DSM SCGI 元件的輸出編碼問題
兩個 Synology 都自評 CVSS 9.8，官方描述的影響包含遠端攻擊者讀寫任意檔案，以及 DoS。
修補門檻：
・DSM 7.4：7.4-90075 以上
・DSM 7.3：7.3.2-86009-4 以上
・DSM 7.2.2：7.2.2-72806-9 以上
・DSM 7.2.1：7.2.1-69057-12 以上
公告的 Mitigation 寫的是 None，也就是沒有「改個設定先擋著」的官方替代方案，只能安裝修補版本。

補充一個細節：對照 DSM 的版本紀錄，這些修補版本其實 6 月就推出了（7.4-90075 是 6/16，其他分支是 6/30），9/18 才公開對應的漏洞。這三個月裡，版本說明只寫「修正了安全性弱點」，沒更新的人看不出裡面有兩個 9.8 分的漏洞。

【2. 10/22：PHP2Shell，以及 Resolved 的讀法】
10/22 的 SA-26:14 處理 CVE-2026-109618、CVE-2026-109619，公告上兩個都是 CVSS 9.8，狀態是 Resolved。（先說明，目前沒有證據顯示 PHP2Shell 跟這波勒索有關。）


這份公告正好可以拿來討論：Resolved 究竟代表什麼？
只看狀態欄，很容易以為「事情結束了」。但去看 revision history，公告之後又修訂了兩次：10/26 新增 Hyper Backup 的條目（目前標為不受影響），10/29 再加入 DSM 6.2、7.0、7.1 這些較舊分支的修補資訊。

另外，同一份公告的產品表裡，PHP 7.3 寫的是「No fix will be provided」，因為已經 EOL。至於 DSM 系統內建的 PHP，群暉的說法是不暴露於外部攻擊面，修補排到之後的 DSM 版本。

所以個人認為，比較合理的讀法是：
Resolved ≈ 廠商針對這份公告界定的範圍，已經提供處理方式。但不一定每個受影響的版本都有修補，PHP 7.3 就是例子。

它不代表：
・所有使用者都已經更新
・所有 EOL 產品都有修補
・產品裡用到同一個 runtime 的元件都已更新
・設備不存在其他攻擊入口
這幾個層次最好分開看。


【3. 10/29：Synology 發布勒索事件聲明】
10/29 Synology 發布新聞稿，表示發現攻擊者正利用一個「2024 年 12 月已修補」的漏洞，攻擊執行舊版 DSM 的設備、加密資料勒索，並引導使用者查看 SA-24:20。
但同一天，360 的反勒索團隊發布分析，把他們處理的 C3RB3R 樣本歸因於 CVE-2026-13639、13684，也就是 9 月的 SA-26:13。
值得注意的是，群暉的聲明只提 2024 年的 SA-24:20。對 360 點名的 SA-26:13，以及有事件應變團隊回報「最新的 DSM 7.4.1-90080 Update 1 也中招」（目前未證實）這兩件事，聲明裡都沒有任何說明。在原廠說清楚之前，使用者其實沒辦法判斷自己的版本安不安全。
另外，10/12 群暉在四個 DSM 分支同時推了安全更新，版本說明只有一句「Fixed security vulnerabilities」，沒有公告編號也沒有 CVE。之前的安全更新大多會附公告編號，這次沒有，使用者無從判斷這次更新修了什麼、有多急。
證據還不足的情況下，我也不想過度下結論。
目前可以說的是：「已有執行舊版 DSM 的設備遭到勒索。」
但如果直接說「所有 C3RB3R 都是 CVE-2026-13639 打進去的」，或「所有案例都是 SA-24:20 那批漏洞」，現有證據都還不夠。
這也是我覺得資安新聞最容易失真的地方：CVE、勒索家族、產品名稱三個關鍵字放在一起，最後常被寫成一條看起來很確定的攻擊鏈。但實際的事件應變不能這樣判。

【4. 「最新版」要問是哪個最新版】
社群裡常看到一句話：「我的 DSM 顯示已經是最新版。」
這句話的資訊其實不夠，要確認的是完整的 build number。例如 SA-26:13 的 DSM 7.2.2 修補門檻是 72806-9，只看到「DSM 7.2.2」是判斷不了的。
而且原廠的 release note 自己也寫了，NAS 不一定會通知你有新版本；部分舊機型甚至收不到那次升級的通知。Tom's Hardware 的評論也提到，群暉似乎沒有直接通知客戶重大漏洞的管道。

套件也是一樣。套件中心沒有顯示更新，不代表裡面每個相依元件都還在上游的支援期內。舉個例子，CyberQ 10/30 的實測發現，Node.js v22 套件更新確實帶進了修補，但同一台機器上，Synology Photos 用的是 Node.js 20，DSM 內建的則是 Node.js 14。版本舊不等於一定有漏洞（SA-26:15 也把 Photos 列為不受影響），但 Photos 的 Node.js 20 在套件中心沒有任何更新可以裝，DSM 內建的 Node.js 14 也只能等系統更新。

【個人結論】
我現在看廠商的資安公告，大概分四層：
1. 漏洞本身是否存在
2. 廠商判定哪些產品真的受影響
3. 修補版本是否已經釋出
4. 我的設備是否真的裝了攻擊面是否已經關閉

公告上的 Resolved，通常只回答到第三層。真正的風險管理，第四層要自己做。
所以「要不要相信廠商公告」可能不是最好的問題。比較好的問題是：廠商的說法能不能被精確界定、交叉驗證，修補狀態能不能對應到實際設備。

作為使用者，我希望看到的是：漏洞出現時範圍說清楚、修補版本列清楚、判斷改變時保留修訂紀錄、不確定的地方就說不確定。


本文整理時間：2026/10/30
有興趣交叉查證的，可以搜尋：
Synology-SA-26:13／SA-26:14／SA-26:15
Synology 2026/10/29「呼籲盡速更新 DSM」新聞稿
360「Cerber勒索攻击群晖NAS事件预警」

CyberQ 2026/10/30 Synology Node.js 更新實測以上供參考，有錯誤的地方歡迎指正。