PHP 在 2026 年 10 月 21 日發布緊急安全更新，修補 CVE-2026-109618、CVE-2026-109619 兩個重大漏洞，CVSS v4.0 評分皆為 9.2。攻擊者可能在未登入的情況下遠端執行程式碼，官方要求使用者儘速更新。 PHP 安全公告
修補版本為 PHP 8.2.35、8.3.36、8.4.27、8.5.12。網站使用 PHP-FPM，也在這次影響範圍內；WordPress 站長則需要確認主機上的 PHP 是否已修補，單獨更新 WordPress 核心無法替換伺服器的 PHP。
PHP 是什麼
PHP 是由 PHP 開源社群維護的程式語言，常用於伺服器端網站開發。瀏覽器送出請求後，伺服器執行 PHP 程式，處理登入、查詢資料或產生頁面，再把結果傳回瀏覽器。它讓網站可以依照帳號與輸入內容產生動態結果。 PHP 官方介紹
WordPress 是使用 PHP 撰寫的網站系統，核心、佈景主題與外掛都透過 PHP 執行環境運作。這次漏洞位於 PHP 執行環境本身，因此除了 WordPress，其他 PHP 網站與應用也需要盤點。PHP-FPM 是管理 PHP 工作程序的常見方式；Apache mod_php 則把 PHP 整合在 Apache 網頁伺服器內。兩者處理請求的流程不同，會影響漏洞觸發條件。
PHP 提前預告安全更新的過程
PHP 官方在正式修補前先公布嚴重程度與發布時間，讓管理者準備更新。依 PHP Foundation 事後說明 ，10 月 20 日約 15:00 UTC，兩個 CVE 編號已在網路流傳，但當時尚未洩漏技術細節；官方因此提前發出預告，並把原定 10 月 22 日 14:00 UTC 的修補提前一天。
| 台灣時間 | 事件 | 已公開資訊 |
|---|---|---|
| 10 月 20 日約 23:00 | CVE 編號開始在網路流傳 | 基金會表示當時尚無技術細節外洩 |
| 10 月 21 日 03:30 | PHP 提前發布預告 | 兩個重大漏洞，評分皆為 9.2，要求準備更新 |
| 10 月 21 日 03:33:47 | 官方公告郵件寄出 | 預定當天 22:00 發布安全更新 |
| 10 月 21 日 22:00 | 預告的協調發布時間 | 修補版本、影響範圍及技術細節配合發布公開 |
上述郵件時間可由 php.announce 原始公告 核對：UTC 時間為 10 月 20 日 19:33:47，換算台灣時間為隔天凌晨 03:33:47，距離預定更新約 18 小時 26 分鐘。
正式發布公告可由 php.announce 郵件清單 核對：四個分支的發布郵件於台灣時間 10 月 21 日 22:00 起陸續寄出。圖中 Docker 的 23:37–23:41，則依四個修補版 FPM 標籤的更新紀錄標示，範圍限於 8.2.35-fpm、8.3.36-fpm、8.4.27-fpm、8.5.12-fpm；各網站何時完成部署，仍取決於自身的更新流程。
修補前為何暫緩公開漏洞細節
暫緩公開利用條件與技術細節，是為了讓維護者和套件商先準備修補，減少攻擊者已能研究漏洞、使用者卻還沒有更新可裝的時間差。這種協調揭露通常設有暫不公開的期限，也稱為 embargo。PHP Foundation 說明，當時發行商仍在打包修正，立即公開會讓許多使用者缺少容易取得的更新，因此選擇提前一天發布，兼顧準備時間與風險。
連提早釋出含修正的二進位檔，也可能讓攻擊者透過比較更新前後的差異推導問題位置。因此協調範圍會包含公告、原始碼、套件與映像的發布時機。本次預告已先公開嚴重度與更新時間，並保留在細節曝光或發現實際攻擊時提前發布的權利。 官方預告存檔
有些網站在完成修補前先預防性停站
有些業者選擇在等待修補時先停止服務。例如千株式会社的「はいチーズ！」服務在 官方公告 中明確指出，因應 PHP 兩個重大漏洞，將在修補套用與安全確認完成前暫停服務；公告當時尚未確認攻擊被害或資訊外流。
pixiv 的維護頁面也呈現類似處置：為在使用中軟體的漏洞修補套用前確保安全，先暫停系統，並預定日本時間 2026 年 10 月 22 日凌晨結束維護。
兩個漏洞如何造成遠端程式碼執行
這兩個漏洞都涉及 PHP 處理請求時的記憶體狀態。遠端程式碼執行（RCE）表示攻擊者可能讓伺服器執行其控制的程式，執行權限限於受影響的網站工作程序（worker）所使用的帳號。
記憶體不足中斷初始化
CVE-2026-109618 發生在記憶體不足（OOM）的錯誤處理流程：請求資料尚未完整初始化時被中斷，清理階段可能把不完整資料當成正常資料使用。 官方技術公告 已驗證在 Apache mod_php 上，HTTP 請求可以於應用程式碼執行前觸發 RCE。
同一公告指出，FPM 在請求啟動失敗時會結束子程序，阻斷上述啟動階段的路徑；但正常啟動後，仍可能由應用程式內的記憶體不足觸發問題。針對這個漏洞，該技術公告記載尚未展示完整 FPM 漏洞利用方式，仍將 FPM 列為可能受影響；PHP Foundation 的事後說明則表示已確認應用程式層級的 FPM RCE。兩份官方說明的驗證狀態不同，均要求更新。
跨請求使用已釋放的狀態
CVE-2026-109619 則是工作程序保留了屬於前一次請求的狀態，對應記憶體已被釋放，下一次請求卻在正常初始化前使用它，造成 use-after-free。 官方技術公告 已驗證 session 生命週期路徑可在 mod_php 與 FPM 達成 RCE；FPM 路徑需要合適的應用程式操作。
這類攻擊需要前後請求進入同一個 worker。多個 worker 會影響每次嘗試的成功機會，無法消除漏洞。Session upload progress 是 PHP 追蹤檔案上傳進度的功能，預設啟用，而且不需要應用程式主動呼叫 session_start() 就可能進入相關處理流程。
受影響環境與修補版本
官方將提供 Web 請求服務的 PHP 安裝列為風險範圍，包含 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 與 LiteSpeed。mod_php 已有應用程式碼執行前的攻擊驗證，官方認為風險較高。 官方影響範圍
| 使用分支 | 有風險的未修補版本 | 本次修補版本 | 官方 Docker FPM 標籤 |
|---|---|---|---|
| PHP 8.2 | 8.2.34 及以前 | 8.2.35 | php:8.2.35-fpm |
| PHP 8.3 | 8.3.35 及以前 | 8.3.36 | php:8.3.36-fpm |
| PHP 8.4 | 8.4.26 及以前 | 8.4.27 | php:8.4.27-fpm |
| PHP 8.5 | 8.5.11 及以前 | 8.5.12 | php:8.5.12-fpm |
| PHP 8.1 與更舊分支 | 需確認供應商回補；未修補前無法排除風險 | 無上游正式維護版本 | 改用受支援分支，或確認供應商映像含修補 |
表中的版本範圍以未回補修正的上游 PHP 為準。Linux 發行版與 LTS 供應商可能把修正回補到既有套件，所以畫面上的 PHP 版本未必會變成表中的上游版號。判斷時應同時核對完整套件版本、供應商安全公告，以及是否涵蓋兩個 CVE。
PHP 8.1 與更舊分支的處理方式
PHP 8.1、8.0、7.x 等舊版環境，建議優先安排應用程式與外掛相容性確認，遷移到受支援且已修補的分支。暫時無法升級時，應向 Linux 發行版、主機商或 LTS 供應商取得回補套件，要求安全公告明列 CVE-2026-109618 與 CVE-2026-109619。 PHP 官方舊版處理說明
官方此次另提供 PHP 7.4、8.0、8.1 的最小原始碼回補，供有能力自行套用修正與建置的環境使用。這些回補不是新的正式維護版本，也不表示舊 Docker 標籤會自動更新。更舊版本若沒有供應商修補，仍需優先規劃遷移；期間可評估限制公開存取，暫時設定只能減少部分攻擊路徑。
網站如何更新與確認修補
更新工作的驗收點是「實際處理網站請求的 PHP 已包含修補」。依照主機管理方式，可以分別確認供應商套件或部署中的容器與服務。更新前應完成備份與相容性檢查。
WordPress 與虛擬主機
WordPress 後台可從「工具 → 網站狀態 → 資訊 → 伺服器」查看 PHP 版本與相關環境資訊。 WordPress 網站狀態文件 若使用虛擬主機或代管 WordPress，可以把兩個 CVE 編號提供給主機商，要求確認修補套件、套用時間，以及是否已讓所有網站 worker 使用新版本。
主機控制台若只顯示「PHP 8.3」這類大分支，還不足以確認安全修補。建議取得完整小版本或供應商回補公告，更新後再核對網站顯示的版本，並檢查登入、表單、媒體上傳與網站主要功能。WordPress 核心、外掛與 PHP 分屬不同更新項目，需各自維護。
自管伺服器與容器
有終端機權限時，可以用下列唯讀指令查看目前命令列使用的 PHP 版本與設定檔位置。 PHP 命令列選項
# 查看目前命令列的 PHP 版本
php -v
# 查看載入的設定檔位置
php --ini這兩個指令檢查的是目前命令列找到的 PHP。多版本主機可能讓 CLI、FPM pool 與 Apache 模組使用不同安裝，還要從網站的服務設定及套件清單交叉確認。容器環境則要核對實際部署的 image 與執行中容器，而非只看開發機或建置主機。
建議先保存資料庫、網站檔案與設定備份，再依原供應商方式安裝修補套件，並按部署流程重新啟動相關 PHP worker。Docker 部署需取得已修補的基底映像、重新建置並替換執行中的容器。完成後記錄套件或 image 版本、worker 更新時間與功能檢查結果，讓後續能回查每個服務是否完成修補。
Docker 官方映像已更新
截至 2026 年 10 月 22 日查核，Docker 官方 php 映像清單已更新至上述四個修補版本，涵蓋 FPM、Apache、CLI 等變體；Docker Hub 也已可查到表中的四個 FPM 修補版標籤。實際使用時，仍需核對所選變體與平台的標籤。 Docker 官方 PHP 映像清單
使用 php:8.3-fpm 這類浮動標籤時，需要重新拉取映像，再依部署流程重建容器；執行中的容器不會因遠端標籤更新而自動替換。若固定在舊小版本或映像 digest（內容識別值），則須先更新引用。 Docker 文件 也說明，docker compose pull 只下載服務映像，不會啟動使用新映像的容器。
自訂 Dockerfile 若以 PHP 為基底，應取得已修補的基底映像、重新建置應用映像，再部署並確認實際執行的 PHP 版本。使用 wordpress、FrankenPHP 或其他應用映像時，需另查該映像維護者的更新與內含 PHP 版本；它們各有發布流程，官方 php 映像完成更新不代表其他映像同步完成修補。
無法立即更新時的暫時措施
官方沒有提供能取代更新的完整設定解法。 暫時措施只減少特定攻擊路徑，應由能管理 PHP 與伺服器資源限制的人員處理，並安排修補時程。 官方緩解措施
針對跨請求狀態問題，官方建議在請求解析前生效的設定中停用 session.upload_progress.enabled，並重新啟動每個 worker；PHP 8.5 另可停用 fatal_error_backtraces，同樣需要重啟所有 worker。ini_set() 與 FPM 的 .user.ini 太晚生效，無法用來阻斷已確認的早期 session 路徑。隱藏錯誤訊息也無法消除問題。 狀態殘留漏洞的緩解限制
針對 OOM 問題，官方提出由管理層強制設定 memory_limit=-1，移除可被控制的 PHP 單次請求記憶體上限失敗路徑。不過這也會取消 PHP 原本的記憶體限制，必須配合前端請求大小限制及外部資源邊界評估；底層記憶體配置失敗仍可能觸發漏洞。官方也提醒不要改用 RLIMIT_AS 或 RLIMIT_DATA，因為它們可能製造同樣危險的配置失敗。 OOM 緩解措施及風險
若暫時無法完成這些設定與資源評估，建議和主機商討論限制受影響服務的公開存取，或暫時提供靜態維護頁。恢復服務前，應完成修補及功能驗收。
常見問答
以下整理版本確認與網站更新時常見的問題。
更新 WordPress 就能修補嗎？
不行，這次需要修補的是執行 WordPress 的 PHP。WordPress 核心更新不會直接替換主機上的 PHP 套件，代管環境應由主機商確認修補狀態。
PHP-FPM 也需要更新嗎？
需要。官方將 PHP-FPM 列在風險範圍，且跨請求狀態漏洞已有特定應用條件下的 FPM RCE 驗證。採用 FPM 的網站仍應完成修補。
沒有看到異常錯誤，是否表示沒有風險？
不是。狀態殘留漏洞公告指出，日誌是否記錄錯誤受設定與執行路徑影響；沒有錯誤紀錄不足以證明安全。更新驗收應以修補套件和實際執行環境為依據。
參考來源
- PHP: Security advisory: Critical remote code execution vulnerabilities, update now (重大漏洞與更新公告)
- GitHub: RCE via OOM corruption (記憶體不足漏洞)
- GitHub: RCE via stale global state (跨請求狀態漏洞)
- PHP: What is PHP and what can it do? (PHP 用途介紹)
- PHP: Command line options (命令列選項)
- WordPress: Site Health screen (網站狀態資訊)
- GitHub: php (Docker 官方 PHP 映像清單)
- Docker: docker compose pull (服務映像下載說明)
- PHP: Upcoming Critical PHP Security Release (安全更新預告郵件)
- The PHP Foundation: Today’s PHP Security Release, and How We’re Strengthening PHP Security (修補與協調揭露過程)
- 千株式会社: 【重要】「はいチーズ！」各サービス 予防措置としてのメンテナンスのお知らせ (預防性維護公告)