根據上一篇報導 C3RB3R 勒索這兩天在 Reddit r/synology 與 BleepingComputer 論壇接連出現受害者，加上 10 月 22 日的 PHP2Shell，Synology 用戶這週的更新壓力不小。同一時間，套件中心也推送了 Node.js v22 的 22.23.4-1011，說明裡一口氣列了 28 個 CVE。
CyberQ 拿一台實際使用中的 Synology DS420+ 做了兩件事，一是驗證這次 Node.js v22 套件更新是否真的帶進上游的修補，二是依前一篇 Synology 勒索與 PHP2Shell 自保文的檢查清單，從外部掃描到登入系統逐項檢查。這邊是簡單的測試心得：
- Node.js v22 套件更新有效，四項可觀察的行為與上游 22.23.4 完全一致。
- 舊版 22.22.3-1010 同時缺了上游 6 月、7 月、10 月三次安全更新，落後約四個月。
- Synology Photos 相依的是 Node.js v20 套件，上游 20.x 已於 2026 年 4 月 30 日終止支援，10 月的修補行為在這個執行環境上都不存在。
- DSM 核心的 Web API 背景程序由系統內建的 Node.js 14.21.1 執行，搭配 OpenSSL 1.1.1q，不在套件中心的更新範圍內。
- DSM 本身已是修補 C3RB3R 相關漏洞的版本，也沒有對外暴露。
測試環境與方法
| 項目 | 內容 |
|---|---|
| 機型 | Synology DS420+ |
| DSM | 7.4.1-90080 Update 1（建置日期 2026/10/02） |
| 已安裝套件 | 25 個，含 Synology Photos 1.9.1、Container Manager、Virtualization、Node.js v20 與 v22 |
| 檢測時間 | 2026 年 10 月 29 日 |
| 檢測方式 | 區網內完整 TCP 掃描與服務辨識、常見 UDP 埠、防火牆轉發規則（唯讀 API）、檢察系統設定、Node.js 離線行為測試 |
檢測過程只做連線、版本探測與讀取設定，沒有對 DSM 發送任何漏洞利用請求。唯一的設定變更是檢測後開啟 DSM 防火牆，變更前先備份原設定，並設定 5 分鐘內未確認就自動還原。
Node.js v22：從 22.22.3-1010 到 22.23.4-1011
28 個 CVE 從哪裡來
Synology 的更新說明只列了 CVE 編號，沒有分類，如果逐一對照 Node.js 官方安全公告，可以觀察到這 28 個編號剛好來自上游三次安全更新：
| 上游發布日 | CVE 數量 | 編號 | 代表性問題 |
|---|---|---|---|
| 2026 年 6 月 17 日 | 11 | CVE-2026-48615、48617、48618、48619、48928、48930、48931、48933、48934、48935、48937 | 代理憑證洩漏到 ERR_PROXY_TUNNEL 錯誤訊息、HTTP/2 伺服器送出 GOAWAY 後仍接收資料 |
| 2026 年 7 月 29 日 | 10 | CVE-2026-56846、56847、56848、56850、58039、58040、58042、58043、58044、58045 | HTTP/2 nghttp2 重入造成 use-after-free（High）、同步 zlib API 可被觸發斷言導致當機、權限模型多處繞過 |
| 2026 年 10 月 21 日 | 7 | CVE-2026-111497、105481、105482、106069、106072、106073、106074 | Brotli 解碼器越界寫入可遠端執行程式碼、TLS 主機名驗證可被繞過、dns.resolve 遇 NUL 字元截斷 |
換句話說，舊版 22.22.3-1010 連 6 月的修補都沒有。上游 7 月的修補版本是 22.23.2，Synology 這次直接跳到 10 月的 22.23.4，中間沒有單獨發布過套件更新。
更新過程
套件中心的紀錄顯示，從下載到完成約 53 秒：
| 時間 | 事件 |
|---|---|
| 23:25:36 | 從 Synology 官方下載 Node.js_v22-x86_64-22.23.4-1011.spk |
| 23:25:46 | 依序停止 Synology Photos、Synology Application Service、Node.js v22 |
| 23:26:27 | Synology Photos 1.9.1 重新啟動成功 |
| 23:26:29 | 記錄「upgrade Node.js_v22 from 22.22.3-1010 to 22.23.4-1011 successfully」 |
要注意的是，更新 Node.js v22 會連帶停止 Synology Photos，即使 Photos 本身跑在 Node.js v20 上。原因是 Photos 相依於 Synology Application Service，而後者相依 Node.js v22（推播服務 VapidSendServer.js 就跑在 v22）。剛好家人正在用手機備份照片時更新，會短暫中斷。
更新是否真的生效
只看版本號不夠，所以特地採用一支不連網的測試程式，檢查 10 月修補中三項可以從外部觀察到的行為變化：
- TLS 主機名驗證（CVE-2026-106069、106072）：以
127.1、0x7f.0.0.1、0177.0.0.1這類非標準 IPv4 寫法呼叫tls.checkServerIdentity()，看是否仍會接受憑證上的 IP 或 DNS 名稱。 - dns.resolve 遇 NUL 字元（CVE-2026-105482）：送出
example.com\0.evil.test，看是被拒絕，還是被截斷後照樣查詢。 - Brotli 解碼器（CVE-2026-111497）：修補新增了錯誤碼
BROTLI_DECODER_ERROR_FORMAT_BLOCK_SWITCH，檢查它是否存在。
同一支程式分別在上游官方映像檔 22.23.3（未修補）與 22.23.4（已修補）、NAS 上的兩個 Node.js 套件，以及 DSM 系統內建的 Node.js 上執行：
| 執行環境 | 非標準 IP 對 IP 憑證 | 非標準 IP 對 DNS 憑證 | dns.resolve 含 NUL | Brotli 新錯誤碼 |
|---|---|---|---|---|
| 上游 22.23.3（對照，未修補） | 接受 | 拒絕 | 照樣查詢 | 無 |
| 上游 22.23.4（對照，已修補） | 拒絕 | 拒絕 | 拒絕 | 有 |
| NAS Node.js v22 22.23.4-1011 | 拒絕 | 拒絕 | 拒絕 | 有 |
| NAS Node.js v20 20.20.2-1018 | 拒絕 | 接受 | 照樣查詢 | 無 |
| DSM 內建 synonode 14.21.1 | 拒絕 | 接受 | 照樣查詢 | 無 |
Synology 的 v22 套件與上游 22.23.4 四項結果完全相同，可以確認這次更新確實帶進了 10 月的修補。OpenSSL 版本也與上游一致，都是 3.5.9。
與上游的差異：zlib 用的是 DSM 系統函式庫
比對 process.versions 後發現一個差異。上游 22.23.4 內附 zlib 1.3.1，Synology 的 v22 套件回報的卻是 1.2.11。檢查動態連結後確認，套件版的 node 連結的是 DSM 系統的 /lib64/libz.so.1，也就是 zlib 1.2.11。v20 套件與 DSM 內建的 synonode 也一樣。
zlib 1.2.11 是 2017 年的版本，上游在 1.2.12 與 1.2.13 修過 CVE-2018-25032 與 CVE-2022-37434。DSM 上這個函式庫的檔案日期是 2023 年 6 月，Synology 是否已把這些修補回移到 1.2.11，從外部無法判斷，可能要再問看看。但可以確定的是，上游 Node.js 隨版本更新的 zlib，不會因為更新 Synology 的 Node.js 套件而進到 DSM 上。
被忽略的兩個 Node.js：v20 與 DSM 內建的 14
Synology Photos 跑在已終止支援的 Node.js 20
這台機器上的 Node.js v20 套件是 20.20.2-1018，套件中心沒有任何可用更新，也不會出現在「有可用更新」的清單上。它存在的唯一原因，是 Synology Photos 1.9.1 的安裝相依條件寫著 Node.js_v20，Photos 的後端 js_server_bundle.js 由這個 node 以 root 身分執行。
上游 Node.js 20.x 已於 2026 年 4 月 30 日終止支援，6 月、7 月、10 月三次安全公告都不再涵蓋 20.x。依 Node.js 官方的說法，每次安全更新發布時，已終止支援的版本一律視為受影響。上面的測試也顯示，10 月修補的行為在 v20 上都不存在。
這不代表 Photos 一定能被攻擊。這些漏洞能否被利用，取決於 Photos 後端有沒有用到相關功能，例如解壓外部來源的 Brotli 資料、以使用者提供的 IP 連 HTTPS、或把外部輸入交給 dns.resolve()，這些都無法從外部確認。但對一般用戶而言，「Synology Photos 跑在一個上游已不再修補的執行環境上」這件事，在套件中心的介面完全看不出來。
DSM 核心用的是 Node.js 14 與 OpenSSL 1.1.1q
更值得注意的是 /usr/bin/synonode。這是 DSM 系統內建的 Node.js，不屬於任何套件，版本是 14.21.1，搭配 OpenSSL 1.1.1q，檔案日期是 2022 年 12 月 9 日。在 DSM 7.4.1-90080 Update 1 上，它以 root 身分執行 /usr/syno/sbin/synoscgi_socket.js，從名稱看是 DSM Web API 的背景程序。
Node.js 14 已於 2023 年 4 月終止支援，OpenSSL 1.1.1 系列也在 2023 年 9 月終止。這支程式只會隨 DSM 系統更新而變動，套件中心的 Node.js 更新碰不到它。這與 Synology 對 PHP2Shell 的說明類似，DSM 內建的 PHP 不在套件更新範圍內，官方評估其不暴露於外部攻擊面，將排入後續 DSM 版本處理。synonode 的實際暴露程度，我們無法從外部判斷，在此只記錄現況。
共用套件的好處，是當 Node.js v22 一更新，Synology Application Service 與 Photos 一起換上修補後的執行環境，PHP2Shell 也是一樣，Synology 的聲明指出，從套件中心更新 PHP 後，相依套件會自動重啟並完成修補。
代價是每個 App 綁定一個主要版本。Photos 綁的是 Node.js v20，上游停止支援後，只要 Photos 還沒改用新版，Node.js v20 就會一直留在機器上，套件中心也不會提示任何更新。至於 DSM 自己內建的 synonode 與 PHP，則完全不經過套件中心。
對於市面上很多 NAS 品牌產品作法的觀察，關鍵還是在廠商的修補上，只要 NAS 廠商的 App 依賴某個版本的執行環境，上游停止支援後，用戶就只能等廠商把 App 移植到新版本。
對用戶而言，實際能做的事情相同，不用的 App 直接移除，少一個 App 就少一份可能過時的執行環境，同時所有的系統更新都建議要優先處理，因為內建在系統裡的執行環境只能靠系統更新替換。
依 C3RB3R 與 PHP2Shell 清單的逐項檢查
DSM 版本與套件
| 檢查項目 | 結果 | 判定 |
|---|---|---|
| DSM 是否達 SA-26:13 修補版本 | 7.4.1-90080 Update 1，高於 DSM 7.4 的修補門檻 7.4-90075 | 通過 |
| DSM 是否還有可用更新 | 系統檢查回報無 | 通過 |
| DSM 自動更新 | 自動安裝重要更新與安全性修補，每週四 02:40 | 通過 |
| PHP 相依套件（SA-26:14） | 未安裝 PHP、Web Station、WordPress、Calendar、Mail Station 等任何一個 | 不在 PHP2Shell 範圍內 |
| 套件可用更新 | Node.js v22 更新後，全部套件皆無可用更新 | 通過 |
| 套件自動更新 | 只自動安裝重要更新，更新頻道設為 Beta | 留意 |
套件更新頻道設在 Beta 會先收到測試版套件，是否適合實際使用中的機器，由用戶自行判斷。另外系統中如果還有跑 WordPress 的系統，以及相關的共用資料夾，對於有使用 Web Station 與 WordPress 的用戶來說，套件的安全性要留意，儘量要減少 PHP2Shell 的攻擊面。
對外暴露
| 檢查項目 | 結果 | 判定 |
|---|---|---|
| 防火牆是否有指向 NAS 的連接埠轉發 | 無，現有轉發規則都指向其他主機 | 通過 |
| QuickConnect | 已停用 | 通過 |
| DSM 管理介面連接埠 | 已改為非預設埠，5000 與 5001 未開放 | 通過 |
| DSM 的 TLS | 只接受 TLS 1.2 與 1.3，加密套件全數為 A 級，憑證為 DSM 預設的自簽憑證 | 通過 |
| DSM 內建防火牆 | 檢測時停用，檢測後已開啟，只放行區網網段 | 已修正 |
實際在產線與辦公室、家用上，NAS 儘量不要有沒有任何路徑從網際網路直接連到 DSM 登入頁，這正是 C3RB3R 受害者的共同缺口。區網內則有 SSH、SMB、DNS 與幾個容器服務開放給需要使用的主機或電腦。
開啟 DSM 防火牆時踩到的坑
檢測後 CyberQ 重新開啟了 DSM 防火牆，只放行區網網段、Docker 內部網段與 IPv6 鏈路本地位址。第一次把規則放在「全部介面」底下，控制台顯示防火牆已啟用，但實際檢查 iptables 才發現，規則只對符合的來源執行 RETURN，鏈的最後沒有任何 DROP，INPUT 預設政策仍是 ACCEPT，等於什麼都沒擋。
原因是 DSM 防火牆的「全部介面」設定區沒有「未符合規則時拒絕」的選項，這個預設動作只能在個別網路介面上設定。把規則改放到各個網路介面並選擇拒絕後，iptables 才在每個介面的規則尾端加上 DROP。我們再從一個不在白名單內的位址連 SSH、SMB 與 DSM 管理埠，三個埠都沒有回應，NAS 上的 DROP 計數器增加了好幾個封包，確認規則確實生效。
建議用戶開啟防火牆後，不要只看控制台的「已啟用」，至少從白名單外的設備實際連一次。如果 NAS 有多個網路孔，每個介面都要各自設定拒絕。
帳號與登入
| 檢查項目 | 結果 | 判定 |
|---|---|---|
| 預設 admin 帳號 | 已停用 | 通過 |
| guest 帳號 | 已停用 | 通過 |
| 登入失敗自動封鎖 | 啟用，5 分鐘內失敗 3 次封鎖 7 天 | 通過 |
| 強制兩步驟驗證 | 未強制 | 未通過 |
| 管理員群組成員 | 除日常帳號外，還有一個測試用管理員帳號 | 留意（測試後刪除） |
| SSH | 啟用且允許密碼登入，telnet 已停用，主機金鑰仍提供舊式 ssh-rsa 簽章演算法 | 留意 |
| SMB | 最低 SMB 2.1，SMB1 已關閉，訊息簽章啟用但未強制 | 留意 |
再次強調，C3RB3R 資安議題這波利用的 CVE-2026-13639 不需要帳號密碼，兩步驟驗證擋不住它。但兩步驟驗證對帳密外洩、同網段電腦中毒後以管理員帳號連入等常見路徑仍然有效，這台機器沒有強制開啟，是應該補上的一環。
備份與快照
這是本次檢測最重要的發現。回顧前一篇整理的 C3RB3R 受害案例，DS1621+ 用戶 12 個共用資料夾中有快照的 4 個全數還原，沒有快照的 8 個全數遺失，Conti v3 系列加密目前沒有公開可用的解密工具。如果沒有啟用快照的機器，一旦被駭客加密，其實是沒有任何復原手段的。
入侵跡象
在所有儲存空間中搜尋 .L0CK3D 副檔名與 read-me3.txt 勒索信，結果為零，也沒有發現異常的系統帳號（如受害者回報的 admin2）、不明的 SSH 公鑰或排程工作，排程也都是正常。
建議處置順序
CyberQ 建議用戶，依風險高低排序做這些事情：
- 立即開啟或確認自己的快照：安裝 Snapshot Replication，為每個共用資料夾設定排程快照與保留期限，並啟用不可變快照。
- 建立版本化備份與一份離線副本：用 Hyper Backup 備到另一台設備或雲端，並保留至少一份備完即拔除的外接硬碟。
- 強制管理員帳號使用兩步驟驗證，刪除測試用管理員帳號。
- 開啟 DSM 防火牆，管理介面、SSH 與 SMB 只允許信任的網段，並在每個網路介面設定未符合規則時拒絕（本次已完成）。
- SSH 改為只接受金鑰登入，不使用時直接關閉；SMB 改為強制簽章。
- 清理 WordPress 殘留帳號與
web、web_packages共用資料夾。 - 追蹤 Synology Photos 何時改用 Node.js v22 以上的執行環境，以及 DSM 何時更新內建的 synonode。
不讓 DSM 暴露在網際網路上、系統更新優先
這次 Node.js v22 套件更新，剛好列出的 28 個 CVE 涵蓋上游三次安全更新，實測行為與上游 22.23.4 一致，更新過程不到一分鐘。比較讓人在意的是兩件事。第一，舊版套件落後上游約四個月，期間 6 月與 7 月的 HTTP/2 use-after-free、權限模型繞過等修補，都沒有單獨推送到 DSM 上。
第二，「Node.js 已更新」不代表這台 NAS 上的 Node.js 都更新了，Synology Photos 仍跑在上游已終止支援的 Node.js 20，DSM 核心的 Web API 背景程序則跑在 Node.js 14 與 OpenSSL 1.1.1q 上，兩者都不會出現在套件中心的更新清單裡。
CyberQ 認為，對一般用戶而言，這些都不是自己能修的問題，只能等 Synology 處理。一般用戶能做、而且應該立刻做的，仍是前一篇的那幾件事，不讓 DSM 暴露在網際網路上、系統更新優先，以及留一份攻擊者碰不到的備份。這台 DS420+ 前兩項做到了，檢測後也補上了防火牆，但最後一項則看個別用戶的備份習慣與有沒有設定好快照。
參考資料
Node.js October 2026 Security Releases
Node.js July 2026 Security Releases
Node.js June 2026 Security Releases
HKCERT，Node.js Multiple Vulnerabilities
