PHP 10 月安全更新：修補版、Web worker 與 Session 設定驗收
終端機的 php -v 已是新版，網站仍可能由另一套 PHP 或未替換的 worker 處理請求。這次升級要留下兩份證據：套件確實包含修補，以及實際服務 Web 請求的程序已使用該套件與設定。
PHP 在 10 月 21 日安全公告列出兩項可導致未驗證遠端程式碼執行的漏洞；10 月 23 日另補充 Session upload progress 提醒。本文於 2026-10-24 檢閱官方資料，提供更新後的驗收方法，沒有執行 PHP 升級、Web worker 測試或漏洞重現。
先核對自己的版本線與供應商修補
兩份官方 advisory 列出的修補版本一致：
| 使用中的版本線 | 10 月 21 日修補版本 |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
CVE-2026-109618涉及 OOM 處理期間未完整初始化的 request 資料；CVE-2026-109619涉及 request 記憶體釋放後仍被 worker 保留的狀態。官方將服務 Web 請求的 PHP 安裝列為風險範圍，不能只因使用 PHP-FPM、FrankenPHP 或 LiteSpeed，就推定不受影響。
若套件來自 Linux 發行版或 LTS 供應商，回補修補的套件可能維持原上游版本字串。此時應比對完整套件版本、供應商公告與這兩個 CVE；只拿 PHP_VERSION 做大小比較，可能誤判。反過來，套件名稱寫著 security 也不夠，要能對應到修補紀錄。
PHP 8.1 與更舊版本已不由 PHP 專案提供例行更新。官方為本次事件另提供部分舊版的最小 source backport，不代表恢復支援生命週期；由供應商確認回補，或規劃移往仍受支援的版本，不要自行假設舊版已安全。
把套件證據連到實際 Web worker
以下是部署後待執行的驗收流程，不是漏洞掃描。先用既有維運入口蒐集資訊，避免臨時開放公開 phpinfo() 頁面。
- 列出所有入口：確認每個站台、FPM pool、Apache 模組或容器實例使用哪一份 PHP。CLI 只代表該終端機找到的執行檔。
- 記錄執行身分：在既有受限診斷入口或內部日誌取得 PHP 版本與 SAPI。官方的
PHP_SAPI／php_sapi_name()可辨認cli、fpm-fcgi、apache2handler等介面；它不是修補狀態證明，還要與前述套件紀錄對上。 - 依服務方式替換 worker：使用部署平台或服務管理器的正常更新、重啟／滾動替換流程，確認舊程序已退出。多副本環境逐一核對，不要用一次成功的負載平衡回應代表全部實例。
- 核對實際設定：從 Web 路徑確認 Session 相關值；只執行 CLI 的
php --ini看不到每個 Web pool 的有效設定。 - 跑正常請求回歸：檢查登入、Session、一般表單、檔案上傳與錯誤處理，觀察失敗率與 worker 重啟情況。健康檢查成功只能證明該路徑可服務，無法證明不存在漏洞。
這條證據鏈的重點是「哪個套件正在處理哪個站台」。保留套件來源、服務／pool、程序替換時間與回歸結果；不要在公開診斷輸出包含環境變數、連線資訊或金鑰。
已更新，為什麼還要看 10 月 23 日提醒？
10 月 23 日公告針對另一個特定組合，預告 CVE-2026-115560 將隨下次 regular bugfix release 提供完整公告。條件是：設定以 php_binary 或 php_serialize 作為 session.serialize_handler，應用程式卻在呼叫 session_start() 前，透過 ini_set() 切換成 php，且 Session upload progress 仍啟用。
官方建議在下次修正前設定：
session.upload_progress.enabled=0若 10 月 21 日已套用這項緩解，保持即可；完全不在 runtime 切換 serialize handler 的應用程式，公告也明確允許保持功能啟用。這個判斷需要一起查設定與應用程式碼，不能只看目前讀回的 handler。套用前確認產品是否使用 PHP 的 Session upload progress，並安排上傳流程回歸。
對 10 月 21 日原本的 session 緩解，官方要求在 request parsing 前生效的 php.ini、FPM pool 或 server 設定套用並重啟每個 worker，不能依賴應用程式內的 ini_set() 或 FPM .user.ini。設定位置與生效時機要跟維運流程一起驗收；Session 設定文件提供各項設定的可變更層級。
不要把這個 PHP 核心問題與 Laravel 的 Session 併發鎖定混在一起。Laravel Session blocking處理請求之間的資料競爭，不能取代 PHP runtime 修補。
緩解設定不能代替原漏洞更新
兩份 10 月 21 日 advisory 都指出，完整修補仍需更新。關掉 upload progress 只涵蓋特定 session 路徑；只調整記憶體限制也不能解決所有 OOM 或狀態生命週期問題。不要把幾個設定照抄成「已修復」的驗收結果。
如果更新造成應用程式回歸，保留錯誤並修正相容性，或使用已確認包含修補的替代建置。回到未修補套件會重新帶回已知風險，不應把它當成沒有代價的回復。網站若有疑似異常，另做事件調查；版本落後本身不證明已被入侵，版本更新也不證明既有入侵已清除。
參考資料：
PHP：2026-10-21 Critical remote code execution vulnerabilities
PHP：2026-10-23 Session upload progress
PHP GHSA：RCE via OOM corruption