PHP2Shell修補到位前：PHP網站如何識別風險與更新
PHP 開發團隊在 10 月 21 日釋出 PHP 8.5.12、8.4.27、8.3.36 及 8.2.35，修補兩項嚴重度達 CVSS v4.0 9.2 的漏洞：CVE-2026-109618 與 CVE-2026-109619。iThome 報道將兩者統稱為「PHP2Shell」；在受影響情況下，未經身分驗證的攻擊者可遠端執行程式碼。
影響範圍不局限於某一款 web server。iThome 指出，所有處理網絡請求的 PHP 系統都可能曝險，包括 PHP-FPM、採用 mod_php 的 Apache、php-cgi、FrankenPHP 及 LiteSpeed。當中 mod_php 的風險尤其值得先處理，因為已有公開資訊展示相關利用途徑。不過，暫時調整設定只能收窄特定攻擊路徑，不能取代安裝修補。
今次漏洞對營運團隊意味甚麼
這是一宗應以「實際執行中的 PHP runtime」為單位處理的事故。網站未必只跑一個 PHP 版本：主網站、後台、舊有子網域、排程工作及容器映像，都可能有各自的 runtime。因此，單靠查看專案原始碼的版本宣告，未必足以確認已經受保護。
建議先盤點每個對外提供服務的 PHP 部署，確認其處理請求的方式、正在運行的版本，以及更新由誰提供：PHP 官方、Linux 發行版、主機代管商，抑或 LTS 服務商。之後再以供應商的修補公告和套件版本核對，而不是假設系統一般更新已涵蓋漏洞。
更新優先次序
| PHP 分支 | 可採取的修補方向 | 需要留意的限制 |
|---|---|---|
| 8.2、8.3、8.4、8.5 | 升級至分別為 8.2.35、8.3.36、8.4.27、8.5.12 或供應商已整合修補的套件 | 更新後應確認實際對外 runtime 已重啟並採用新版本 |
| 7.4、8.0、8.1 | 向所用 Linux 發行版或 LTS 服務商查詢回植修補；有能力的團隊可採用已移植修補的原始碼自行編譯 | PHP 專案沒有直接提供這些已停止支援分支的正式更新版本 |
對仍依賴 PHP 7.4、8.0 或 8.1 的機構而言，難點在於「有修補可用」不等於「可像受支援分支般直接升版」。iThome 指出，開發團隊已把相關修補移植至這些舊分支的原始碼；但實際能否透過套件取得，取決於發行版或 LTS 供應商。這亦意味內部自行編譯的 legacy server，修補驗證和後續維護成本會較高。
漏洞為何需要迅速處理
iThome 報道指出，CVE-2026-109618 與記憶體耗盡（OOM）時的內部請求資料清理有關：當資料只完成部分初始化，錯誤處理可能把無效資料當成有效資料使用。CVE-2026-109619 則涉及 worker 處理後續請求時，可能沿用已釋放備份記憶體留下的過時內部狀態。
對網站營運者來說，這些成因的共同訊號是：問題位於 PHP 處理請求的底層流程，未必能靠修改單一 app、關閉某個外掛，或在 WAF 加上一條規則便徹底化解。較合理的應對，是把公開入口的 PHP runtime 視為優先修補目標，同時檢查是否有被遺忘的舊站、管理介面或長時間未重建的映像。
修補完成後，下一步應是持續追蹤所用發行版、LTS 供應商及主機代管平台的更新狀態，特別是仍未完成 PHP 升遷的舊系統。
延伸閱讀
AI 輔助說明： 本文由 AI 協助整理，並經兩輪獨立自動品質審核；資料及連結仍以原始來源為準。
參考來源
- iThome — PHP發布緊急安全更新，修補已有概念驗證程式碼的重大漏洞PHP2Shell — original report
本文根據原文及公開資料整理；資料有出入時，以原文及官方資料為準。
