PHP 官方於 2026 年 10 月 21 日發布緊急安全更新，修補俗稱 PHP2Shell 的兩個高危漏洞。使用 WordPress 的站長，現在要向主機商確認的是：網站實際使用的 PHP 是否已套用修補，以及更新後的工作程序是否已重新啟動。只在 WordPress 後台按下核心、主題或插件更新，無法完成這次 PHP 執行環境的修補。
PHP2Shell 影響哪些網站？
這次涉及 CVE-2026-109618 與 CVE-2026-109619，官方預告列出的 CVSS v4.0 評分均為 9.2。問題出在 PHP 核心處理請求與記憶體的方式，可能讓未登入的遠端攻擊者執行程式碼。
PHP 官方把所有提供網頁請求的 PHP 安裝列為風險範圍，包括 PHP-FPM、Apache 的 mod_php、php-cgi、FrankenPHP 與 LiteSpeed。當中 mod_php 的風險被列為最高，已有在應用程式碼執行前觸發攻擊的示範。因此，網站有登入頁、關閉會員註冊，或沒有讓訪客上傳檔案，都不能直接當成安全判定。
兩份上游公告分別描述記憶體耗盡時的狀態損壞，以及前一次請求留下的全域狀態引用了已釋放的記憶體。這也解釋了為何處理範圍會超出單一 WordPress 插件：維護者需要檢查主機上的 PHP 本身。
先對照分支，再確認修補來源
PHP 官方已發布下列修補版本；若採用上游版本，請更新至所屬分支的這個版本或更新版本。
- PHP 8.2：8.2.35。
- PHP 8.3：8.3.36。
- PHP 8.4：8.4.27。
- PHP 8.5：8.5.12。
由 Linux 發行版或長期支援供應商維護的套件，可能採用回移補丁：保留原本的基礎版本號，把安全修正加進套件。例如 Ubuntu 官方列出，24.04 的修補套件為 8.3.6-0ubuntu0.24.04.13，22.04 則為 8.1.2-1ubuntu2.28。不能因為畫面仍顯示 8.3.6，就斷定它一定沒有修補；也不能只聽到「有自動更新」就認定完成。請核對完整套件版本和供應商公告。
PHP 8.1 及更舊版本已不再獲得 PHP 專案的正常更新。官方這次提供了 7.4、8.0、8.1 的最小原始碼回移修補，供特定維護情境使用，並不代表這些分支恢復支援。若主機商無法提供相應修補，應安排遷移至仍受支援的 PHP 版本，先確認網站、主題與插件的相容性。
WordPress 站長可以怎樣向主機商確認？
先登入自己的 WordPress 後台，在「工具 → 網站狀態 → 資訊 → 伺服器」查看 PHP 版本；不同語言的選單名稱可能略有差異。這是盤點的起點，完整修補狀態仍應由主機商或伺服器維護者確認。可把以下問題連同自己的網域交給對方：
- 這個網域目前由哪個 PHP 執行環境、版本及套件處理？請提供完整版本或建置資訊。
- 是否已修補 CVE-2026-109618 與 CVE-2026-109619？若用回移補丁，請提供對應公告與套件版本。
- 更新後，處理這個網站的 PHP-FPM 工作程序或 Apache 等服務是否已重新啟動？
- 同一帳號的其他網域、子網域或不同 PHP 版本，是否也已逐一確認？
自行管理伺服器時，命令列的 php -v 只能顯示目前命令列選到的 PHP；它未必就是網站使用的版本。若以容器部署，還要確認映像已包含修補、運行中的容器已更新，不能只修改映像標籤或下載新映像後便結案。更新前先保存可還原的網站與資料庫備份，安排適當維護時段。
Ubuntu 公告特別提醒，安裝更新後仍可能需要重新啟動使用 PHP 的應用程式；例如 Apache 搭配 mod_php，需要重新啟動 Apache。具體服務名稱與操作交由熟悉該主機的維護者確認，避免在多站共用主機上重啟錯誤服務。
暫時關閉上傳功能，能不能先擋住？
官方明確指出，完整解法是更新。調整 session.upload_progress.enabled 等設定，只能減少特定攻擊路徑，不能讓未修補的安裝變得安全。這些設定還涉及生效位置與工作程序重啟，直接把一行設定貼進應用程式碼，不能取代主機層修補。
若暫時無法更新，請維護者依官方公告評估限制入口與其他緩解措施，同時確定修補時程。不要在正式網站執行來路不明的漏洞驗證腳本，也不要用別人的網站測試。網站照常顯示、沒有報錯或尚未收到告警，都不足以證明不受影響。
更新後，怎樣確認網站能正常使用？
請維護者保留修補版本、套件來源及重啟時間，再以網站實際使用的環境複核。站長可用自己的測試帳號檢查首頁、登入、文章頁、表單，以及網站原有的上傳或交易流程；涉及付款時使用既有的測試環境與測試方式。
若已發現陌生管理員、檔案被改寫或其他入侵跡象，請保留紀錄並交維護者處理。套用補丁處理的是漏洞，既有入侵仍需要另外調查與清理。
評論0