工程師思路系列・事出必有因
NAS 架站的四道難題：更新不動、換機不實際、放著不管、廠商不扛，然後呢？
Mr. τ ｜ 風雲網通系統 ｜ 2026-10-21 晚間
今天（10/21）PHP 官方釋出緊急安全更新，修補兩個 CVSS v4.0 評分 9.2 的遠端程式碼執行漏洞（代號 php2shell，CVE-2026-109618、CVE-2026-109619）。WordPress 核心的 CVE-2026-87902 則早在 9/22 就已修補，並已被美國 CISA 列入「已知遭利用漏洞」清單。
這篇不是漏洞通報，我已經另外在社團發過。我想談的是：當你的網站架在一台更新不動的 NAS 上，到底該怎麼辦。

一、這不是你一個人的問題

我自己的官網，最早是一台自己安裝套件的 PC Linux 主機。後來考慮到費電，改用 NAS，前後換過兩代。每一步都合理：省電、省維護、快速上線。

大家平常都忙著日常工作，建站這件事，本能就會挑「懶人包」。就算本職是工程師，也一樣：能省時間的 Appliance，就用 Appliance。

但 Appliance 賣的是「不用自己維護」，這個承諾有一個隱含條件：廠商要持續維護。型號老舊、原廠不再支援的那天，承諾就消失了，而網站還掛在外網上，沒有人通知你這個條件已經不成立。

二、為什麼更新總是被拖

更新的成本是現在就要付的：

✔

先備份網站、資料庫、系統與設定
✔

嘗試升級，失敗要能退回
✔

就算成功，可能還要轉換一些設定與規格檔案

更新的回報卻是看不見的：做好了，什麼都不會發生；沒做，也往往很久都不會出事。所以只有兩種情況會認真做：有人付維護費，或是出事之後。

有維運責任的工程師，其實都不想碰這件事，但早晚會遇到。這是痛點，不是疏失。

三、四道難題

把處境攤開，會發現是四個條件互相卡住：

1

NAS 的網站功能好用，會繼續用。內建功能方便、上線快，沒有理由放棄。
2

三五年就買一台新 NAS，只為了讓官網部落格的 WordPress 能被支援，不實際。
3

不維護、不保護，也不合理。網站掛在外網，就是有人會來敲門。
4

廠商不會替你扛套件（PHP、WordPress）的即時更新責任。這是我的觀察：各家 NAS 廠商的人力有限，光是追上型號與作業系統的相容清單就很吃力，更別說不斷翻新套件的相容版本。這不是各廠商的正式說法，是我在這個產業多年的實際感受。
以這次為例（截至 10/21 晚間）：PHP 修補版釋出才幾個小時，我還沒有看到 Synology 針對這兩個 CVE 的公告或對應的 PHP 套件更新。另外，我在 DS925+ 的 WordPress 套件發行資訊看到的套件版本是 6.8.6，而 6.8 分支針對 CVE-2026-87902 的修補版本是 6.8.10。版本號後面的建置號可能包含回補，所以這一點請以 Synology 官方更新紀錄為準，發文前我也請你自行核對。

四難卡住的人，最常見的反應是「那就不管了」。放著不理也是一種選擇，但那是「選了」，不是「沒選」。下面把選項攤開，讓你知道每個選擇的代價。

四、誰負責哪一層

層級 誰負責 現實狀況
硬體與 NAS 作業系統 廠商 型號停止支援後就結束
PHP、WordPress 套件 廠商打包，更新落後上游 套件是第三方軟體，要逐型號、逐系統版本測試與打包（我的觀察）
外掛、佈景主題、網站內容 使用者 廠商不會碰
入口與暴露面（誰連得到你） 使用者 最能立刻降低風險的一層

廠商不會即時負責，就把自己能控制的那一層守好。這比抱怨廠商實際得多。

五、風險到底長什麼樣

✔

有弱點，不等於被攻破；但暴露加上時間，機率會累積。WordPress 的 CVE-2026-87902 要在特定條件下才能升級成遠端執行（例如佈景主題的目錄結構、伺服器上有可被載入的 PHP 檔案），沒滿足條件的站，弱點存在但打不穿。可是自動化掃描不挑對象：據報導，攻擊在修補當天就出現；CrowdSec 在五天內就看到三萬多個 IP 送出相符請求；CISA 也在 9/25 把它列為已知遭利用。
✔

PHP2Shell 影響面很廣。官方指出，所有對外處理網頁請求的 PHP 環境都在風險內，影響版本可回溯到 PHP 5.4，其中 Apache mod_php 風險最高。Cloudflare 已觀察到早期攻擊嘗試；截至本文查核，我尚未找到足以確認 PHP2Shell 已在野外成功入侵網站的可靠公開證據。但這不代表沒有，更不代表未修補的網站可以放心。
✔

被打進來之後，傷的不只是網站。網站被改寫、被掛上惡意內容、被當成跳板，資料庫帳號與 wp-config.php 裡的密碼與金鑰也可能外洩。備份救得回網站，救不回已經被拿走的東西。
✔

形象型、行銷型網站，真正的損失常常是信譽。網站若被掛上惡意內容，可能被瀏覽器或搜尋引擎標示警告，客戶看到的就是「這家公司的網站有問題」。

六、五種抉擇與能接受的結果

非關鍵任務的網站（形象型、行銷型），管理者與擁有者都會面臨這個抉擇。下表列出我認為實際可行的五種做法，以及做完之後還剩下什麼風險：

做法 做了什麼 降低什麼 剩下的風險
A. 放著不理 什麼都不改 沒有 暴露面與弱點全在，被掃到只是時間問題。前提是你有可靠的備份，而且能接受網站被打垮
B. 前面擋，縮小暴露面 Cloudflare 代理；來源端只收 Cloudflare 網段；管理後台走 VPN；關掉用不到的對外連接埠；清掉不用的主題與外掛 大幅降低被直連、被隨機掃到的機會 PHP 與 WordPress 本身的洞還在；WAF 規則可能被變形攻擊繞過
C. 靜態化 WordPress 留在內網當編輯端，把網站匯出成靜態頁，發布到託管環境 對外不再執行 PHP，攻擊面最小 留言、表單、站內搜尋等動態功能要另找替代；編輯端仍要保護；匯出外掛的相容性要先測試
D. 搬到有人持續維護的環境 託管主機，或較新的 NAS 上用容器（例如官方 WordPress 映像檔）運行 把 PHP 與 WordPress 的更新責任移出舊機器 一次性的搬遷成本；新環境的更新仍然要有人看
E. 下線，或只留靜態名片頁 關掉 PHP 站台 攻擊面歸零 失去網站功能；適合沒人維護且功能可有可無的站

這些做法可以組合。B 是最快、成本最低的起點，C 或 D 是長期方向，而備份是所有選項共同的底。不論選哪一個，重點是知道自己選了什麼，也知道剩下什麼風險。

提醒：暫時緩解措施不是修補。PHP 官方針對兩個 CVE 提出了不同的緩解路徑，而且強調只有更新才是完整解法：
CVE-2026-109619：把 session.upload_progress.enabled 設為 0 並重啟所有 PHP worker，必須在請求解析前生效（php.ini、FPM pool 或伺服器設定），只能擋住已確認的 session 路徑。
CVE-2026-109618：官方建議把 memory_limit 設為 -1 並讓應用程式無法覆寫，同時降低 post_max_size，並在網頁伺服器或代理層限制請求大小；官方警告不要用 RLIMIT_AS、RLIMIT_DATA 代替，應改用容器或 cgroup 做資源隔離。在記憶體有限的 NAS 上不限制記憶體，可能讓單一程序吃光資源，所以我不建議一般使用者自行套用。

七、最後一道防線：備份與善後

我的官網有異機、異地的網站與 WordPress 備份任務在執行，所以就算主網站被打垮，我不會太驚心動魄。備份是「撐住與復原」的那一層。但備份有四個容易被忽略的盲點：

✔

還原測試過嗎？備份有在跑，不代表能還原。定期在另一台機器實際還原一次，確認網站與資料庫都能起來。
✔

備份可能帶著後門。如果入侵發生在幾週前，最近的備份可能已含被植入的檔案。保留多個時間點的版本，還原時往前挑乾淨的。
✔

備份救不回已外洩的東西。資料庫內容、wp-config.php 裡的資料庫密碼與金鑰，被入侵後要整批更換，不能只還原了事。
✔

備份目標要和網站隔離。被入侵的主機不應有權限寫入或刪除備份，否則備份會跟著一起被清掉。

站被打垮之後，我會這樣走：

1

先下線或隔離。不要讓被攻破的站繼續對外。
2

換憑證。WordPress 管理員、資料庫、金鑰，以及和其他系統共用的密碼。
3

挑乾淨的版本還原。往前找入侵發生之前的備份。
4

檢查可疑跡象。不認得的 PHP 檔案、新增的管理員帳號、被改過的主題檔案，再搭配存取記錄與錯誤記錄。
5

先縮小暴露面，再重新上線。不要原封不動地放回同樣的環境。
# 路徑請換成你的網站目錄。這些只是調查線索，沒找到不代表安全
find /你的網站目錄 -name “*.php” -mtime -14
find /你的網站目錄/wp-content/uploads -name “*.php”

第一行列出最近兩週有變動的 PHP 檔案；第二行找出上傳資料夾裡的 PHP 檔案，這裡通常不該有，出現了值得查證。單獨出現這些跡象，不足以確認入侵。

八、現況查核（截至 2026-10-21 晚間）

狀態 內容
已確認 PHP 官方於 10/21 釋出 8.5.12、8.4.27、8.3.36、8.2.35，修補兩個 CVSS 9.2 的漏洞；PHP 8.2 將於 2026/12/31 終止支援。PHP 團隊另外為 7.4、8.0、8.1 提供了最小化的源碼回補，但這不代表這些分支恢復支援。
已確認 Cloudflare 自 10/21 台灣時間上午 11:02 起，為所有方案（含免費版）預設部署 php2shell 防護；它只對實際經過 Cloudflare 代理的流量有效，也不取代修補。
已確認 WordPress CVE-2026-87902 於 9/22 修補（7.1.2，並回溯到各維護分支），CISA 於 9/25 列入已知遭利用漏洞清單。10/6 另有 7.1.3 釋出。
待確認 Synology 針對兩個 PHP CVE 的公告與套件更新；Synology 的 WordPress 套件是否已回補 CVE-2026-87902（我看到的套件版本為 6.8.6，低於 6.8 分支修補版 6.8.10，建置號可能含回補，請以官方更新紀錄為準）；PHP2Shell 是否已有成功入侵的公開案例。

以上狀況會持續變動，我會在下方補上更新紀錄。
更新紀錄：2026-10-21　初版。

結語

四道難題沒有任何一個做法能單獨解開，但可以拆開處理：入口自己守，網站盡量不要在對外時執行 PHP，備份是最後一道防線。
你無法讓風險歸零，但能讓它變小、能撐住，也能復原。最誠實的選擇，是知道自己選了什麼，包括「放著不理」。

#PHP2Shell　#WordPress　#NAS　#Cloudflare　#備份　#工程師思路
Last modified: 2026-10-22

Author

Comments

Write a Reply or Comment

Your email address will not be published.