成因概念

一句話

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

兩個 CVE 是同一類失敗的兩個面孔：

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

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

為什麼應用程式擋不住

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

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

三個被點名的面向

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

1. session upload-progress

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

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

2. OPcache

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

3. 致命錯誤 backtrace

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

影響面

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

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