更新及查核日期：2026-10-30
網站仍能開啟、遠端工具仍可連線、NAS 仍有備份工作執行，不代表相關系統已完成安全更新。2026 年 10 月多項公告涉及企業常用軟件，處理時應先確認公司是否使用受影響的產品、版本及功能，再安排相應行動。
本文選取六個有官方公告支持的主題。「六大」代表本次整理的六項重點，並非按受害數量或損失排出的全球排行榜。漏洞公告、已確認的攻擊及供應鏈事故亦須分開理解。
六項議題與公司資產對照
| 議題 | 先找誰核對 | 優先確認甚麼 |
|---|---|---|
| PHP2Shell | 主機商、網站開發人員 | 實際執行的 PHP 分支與修補狀態 |
| TeamViewer | IT、遠端支援負責人 | 平台、客戶端版本及連線用途 |
| Synology DSM | NAS 管理員 | DSM 版本、對外服務與恢復能力 |
| Brotli／Node.js | 應用開發及部署人員 | 執行環境及內嵌依賴 |
| LiteLLM | AI 應用及部署負責人 | 是否安裝或執行涉事發布 |
| WordPress | 網站維護方 | 核心安全更新及更新責任 |
表格是分工起點。企業應把實際資產、外部暴露程度及業務重要性加進清單，不能僅憑產品名稱判定已遭入侵。
一、PHP2Shell：更新網站程式，還要檢查 PHP
PHP 官方於 10 月 21 日公布安全修補，處理 CVE-2026-109618 及 CVE-2026-109619；公告指出漏洞可導致未經驗證的遠端程式碼執行。應由負責人核對相應分支的安全版本或供應商修補套件，而非只檢查網站內容是否正常。PHP 官方公告
企業自查時，可要求主機商列出正式環境使用的 PHP 版本、修補來源及完成時間。若公司有多個網站、背景工作或獨立應用，應逐一核對，不能把某個控制台顯示的設定視為全部系統的證明。
網站核心、外掛與 PHP 執行環境由誰負責，也應寫清楚。更新其中一層不會自動證明其他層已完成維護。
二、TeamViewer：RCE 有利用條件，更新範圍須看平台
TeamViewer TV-2026-1011 於 10 月 27 日公布、28 日更新，列出多項客戶端漏洞，最高 CVSS 為 8.8。當中部分涉及遠端程式碼執行及使用者互動；不同平台及漏洞的受影響範圍不能混為一談。官方公告當時表示未發現實際利用。TeamViewer 安全公告
公司應盤點員工電腦、支援人員裝置及由外判方維護的安裝，按各平台核對修正版本。亦應確認誰可以發起或接受遠端工作階段，以及錄製檔的來源。
「已安裝更新」與「所有裝置均完成更新」是兩個問題。維護紀錄應保留裝置範圍、版本與完成日期，避免只更新最常用的一部電腦。
三、Synology NAS：近期勒索攻擊利用的是舊漏洞
Synology 於 10 月 29 日指出，攻擊者利用 2024 年 12 月已修補的漏洞，針對舊版 DSM 裝置加密資料並勒索。官方呼籲受影響用戶更新 DSM，並參考 Synology-SA-24:20。本次公告未提供可支持「大規模受害」的數字。Synology 官方公告
管理員應核對裝置及版本是否在公告範圍，並審視哪些服務直接對外。業務上不需要的對外入口，應經評估後收窄，而不是把更新以外的暴露面一直保留。
備份亦要獨立檢查：是否有不依賴同一管理帳戶及裝置的副本？最近一次恢復測試能否取回所需檔案？排程顯示成功，只能證明某次工作完成，不能取代恢復測試。
四、Brotli／Node.js：內嵌依賴也要納入盤點
Node.js 10 月 21 日安全發布包含 Brotli 解碼器漏洞 CVE-2026-111497。處理不可信壓縮資料的相關應用需要核對影響；不能據此宣稱所有 Node.js 網站已遭攻擊。Node.js 官方安全發布
對企業而言，難點可能是應用帶有自己的執行環境或容器映像。只更新伺服器某一份軟件，未必處理所有部署。請開發與維運人員確認實際運行的是哪個版本、是否已重新部署，以及舊實例是否仍在服務。
驗證不宜只停留在「套件已下載」。應確認正式環境已使用預期版本，並測試業務功能是否正常。
五、LiteLLM：供應鏈事故需要連同憑證調查
LiteLLM 10 月 23 日的調查報告確認，10 月 21 日發布的 v1.107.0 遭污染，涉及其發布流程。官方指這份報告取代初期調查中不完整或不準確的推測，故判斷事故應以更新後的紀錄為準。LiteLLM 正式調查報告
企業應先確認是否下載、部署或執行相關發布，保存適當的部署及存取紀錄，再按事故指引評估影響。涉及憑證的供應鏈事故，不能只以移除套件便判定處理完成；仍需核對受影響環境的密鑰、權限與存取活動。
這項事件針對具體產品與發布，不代表所有 AI 工具均受影響。內部溝通應列明證據與範圍，避免把潛在暴露寫成已確認資料外洩。
六、WordPress：安全更新要有持續責任人
WordPress 安全團隊 10 月 29 日的回顧列出近期多次安全發布，包括 10 月 28 日的 7.1.4。網站維護不能只等畫面或功能出問題才開始。WordPress 安全團隊更新
公司應確認核心版本、更新安排及負責人，同時把外掛、佈景主題及主機環境納入維護流程。本項聚焦網站核心與管理；前述 PHP 題目則處理執行環境，兩者不能互相代替。
更新前按業務需要準備備份及測試，完成後驗證登入、表單及關鍵流程。驗證結果與例外情況應留有紀錄，方便下一次維護接續處理。
如何決定先處理甚麼？
先處理已有疑似入侵跡象的環境，並由負責人保存紀錄、評估隔離及通知程序。對其餘資產，再看是否符合漏洞條件、是否對外暴露、相關攻擊證據、資料重要性及可用修補安排。
可把每項工作記成「資產、負責人、影響判斷、處理期限、驗證結果」。CVSS 是參考之一，並非唯一排序依據；對外且載有重要資料的系統，與沒有使用涉事功能的內部測試環境，需要不同判斷。
常見問題
有防火牆是否可以不更新？
防火牆與軟件修補處理不同層面的風險。不能把一項控制措施視為全面取代更新的證明。
有 NAS 是否就有獨立備份？
要看副本所在位置、管理權限、保留方式及恢復測試。單有 NAS 或磁碟冗餘不足以回答這個問題。
更新後是否代表一定沒有入侵？
修補與事故調查目的不同。如有異常活動，仍需檢查相關紀錄與影響。
公司沒有專職 IT，可以怎樣開始？
先列出主機、網站、NAS、遠端工具及 AI 應用的管理者，向各供應商取得版本及維護確認，再整理尚未有人負責的項目。
本文不構成對個別系統的安全認證；公告與版本資料亦應在實際處理時再次核對。