成因概念

一句話

PHP 處理網頁請求時，若在記憶體不足或致命錯誤的當下被迫立刻中斷（研究者稱為 bailout），可能留下只初始化一半或已經過期的內部狀態。之後的清理或下一個請求，可能把這份殘留當成有效資料。

兩個 CVE 是同一類失敗：

註：CVE

CVE

這次是 CVE-2026-109618 與 CVE-2026-109619。外洩貼文曾把分數寫成 10.0，官方 CVSS v4.0 是 9.2。

CVE	官方名稱	官方在說什麼
CVE-2026-109618	RCE via OOM corruption	記憶體不足的處理可能在內部請求資料只初始化一半時中斷 PHP，請求清理可能把無效資料當成有效
CVE-2026-109619	RCE via stale global state	請求擁有的內部狀態可能在記憶體釋放後仍存活，同一 worker 的後續請求可能在正常初始化重設前使用它

Imperva 把兩者都歸為 CWE-824（存取未初始化的指標），並提醒：能從遠端觸發，和能穩定變成 RCE，難度不是同一件事。這不降低「必須更新」的結論。

註：CWE-824、RCE

CWE-824（CWE）

Imperva 把這次歸成 CWE-824，意思是程式去用了一個還沒準備好、不能當真的內部指標。

RCE

Remote code execution，遠端程式碼執行。未登入的呼叫者有機會讓伺服器執行他指定的指令。這次兩個 CVE 的官方後果都包含未授權 RCE；名稱裡的 shell 不代表每一個請求都必然走到那一步。

為什麼應用程式擋不住

問題可以發生在應用程式碼開始執行之前。Wiz 與 Imperva 都用「一行 echo 的網頁」說明這點：自家程式再乾淨，也會曝險。所以 WordPress、Drupal、Magento 的應用更新不是這次的修補，應用層的防護也擋不住這個時機。

會反覆處理許多請求的 worker 是關鍵：下一個請求可能在正常初始化把狀態清掉之前，就碰到上一個請求留下的殘留。這也是修補之後一定要重啟所有 worker 的原因。

註：worker

worker

處理網頁請求的 PHP 行程。同一支 worker 接下一個請求時，可能在正常初始化把殘留狀態清掉之前就用到它。修補後要重啟所有 worker。

三個被點名的面向

下面只說明「在哪裡、官方如何對應、擋得住什麼」。

1. session upload-progress

PHP 預設會記錄上傳進度，對應設定 session.upload_progress.enabled，出廠為開。這是已展示路徑裡常見的遠端入口，但不是唯一入口。Wiz 指出後果分兩類：記憶體破壞以致 RCE，以及經回應裡的 session cookie 讀到行程記憶體；後者在應用程式從未啟用 session 時仍成立，讀到的可能包含密碼、token 與 API 金鑰。

註：上傳進度、session

上傳進度（session upload-progress）

對應設定 session.upload_progress.enabled，出廠為開，是這次已被確認的遠端入口之一，但不是唯一入口。暫時措施是在請求開始解析前生效的設定裡關掉它，並重啟所有 worker；ini_set() 與 .user.ini 來不及。它擋不了 OPcache 與 backtrace 那些變體。

session

伺服器端狀態，用來把一連串請求認成同一位訪客。這次與上傳進度、PHPSESSID 有關；應用程式沒有呼叫 session_start() 時，讀到行程記憶體這件事仍可能成立。

官方暫時措施是在請求解析前就生效的設定裡關掉它並重啟所有 worker。它擋不了下面兩個面向。

2. OPcache

OPcache 把編譯結果放在可重複使用的共享快取。請求若在錯誤時刻中斷，快取裡可能留下已配置卻沒正確完成的項目，後續請求可能誤用。因為狀態在共享快取裡，影響不限於「剛好打到同一支 worker 的下一個請求」。JFrog 寫明：關掉上傳進度不會蓋住這一條。

註：OPcache

OPcache

把已編譯的程式放進可重複使用的快取。請求若在錯誤時刻中斷，快取槽可能處於已配置卻未正確發布的狀態，後續請求可能誤用。關掉上傳進度不會蓋住這條路。

3. 致命錯誤 backtrace

致命錯誤留下的回溯資訊，可能在所屬記憶體釋放後仍被當成有效狀態。PHP 8.5 的官方暫時措施是 fatal_error_backtraces=0 並重啟所有 worker，只擋這條已確認的路徑。

註：回溯

回溯（backtrace）

致命錯誤留下的回溯資訊，可能在所屬記憶體釋放後仍被當成有效狀態。PHP 8.5 的暫時措施是 fatal_error_backtraces=0 並重啟所有 worker。官方說這只擋已確認的 backtrace 路徑。

影響面

兩類後果：未驗證的遠端執行程式，以及讀取 PHP 行程記憶體。記憶體裡可能有其他請求或伺服器的密碼、驗證 token、API 金鑰、憑證。讀取記憶體不需要先達成 RCE。不需要應用程式帳號。不限 WordPress、Drupal、Joomla，連 Hello World 也算。WAF、CDN 與主機商規則不能取代更新。判斷步驟見我受影響嗎？。

註：WAF、CDN

WAF

Web Application Firewall。Cloudflare 自 2026-10-21 03:02 UTC 對免費與付費客戶預設上線規則，仍必須更新 PHP。已看到有人變造請求試圖避開規則。研究團隊寫，WAF、CDN 或主機商規則不能取代更新。

CDN

Content Delivery Network。研究團隊寫，CDN、WAF 或主機商的規則視廠商與路徑而定，不能取代更新 PHP。Vercel、Cloudflare、Akamai 都有自己的規則，直接打到源站的請求可能不在涵蓋範圍。

Calif 經 Sansec 列出曾展示未授權 RCE 的應用：Magento、WordPress、Drupal、Joomla、MediaWiki、Roundcube、phpMyAdmin、Nextcloud、Laravel、Symfony、WHMCS。這份清單說明影響面，不是說其他應用就沒事。

程式碼被認為可回溯到 PHP 5.4.0（2012），但並非每一個歷史版號都經過逐一驗證；Wiz 稱過去十年發布的每個版本至少受其中一個漏洞影響。兩句是研究者的結論，不是官方的完整版本矩陣。