PHP php2shell：請求中途失敗仍可能留下狀態

將 PHP 執行環境本身升級至 8.5.12、8.4.27、8.3.36 或 8.2.35，或安裝供應商提供的回移修補套件，並重新啟動所有工作程序。更新 WordPress、Drupal、Laravel 或外掛程式，無法修復這個漏洞。10月21日披露的兩個漏洞 CVE-2026-109618 和 CVE-2026-109619（「php2shell」）存在於執行環境本身，層級低於應用程式碼。

這就是為甚麼加拿大政府的多個網站、STM 網站和 SAQ 網站在週三採取預防措施下線。網站下線直至完成修補，是一項直接但粗略的控制措施；不過，對於一個能在任何應用程式碼執行前觸發的漏洞，這做法是合理的。

以下是我希望團隊在關閉工單前瞭解的內容：問題出在哪裏、暫行設定能帶來甚麼保障和不能解決甚麼，以及背後的設計教訓。

問題出在哪裏

PHP 安全團隊將兩個 CVE 均評為嚴重（CVSS v4.0 9.2）。其安全公告描述了兩個相關問題：

CVE-2026-109618：記憶體不足處理程序可能在內部請求資料只完成部分初始化時中斷 PHP，之後請求清理程序可能會將該資料視為有效。
CVE-2026-109619：由請求持有的狀態可能在其記憶體釋放後仍然保留，而同一工作程序處理的後續請求，可能會在正常初始化程序重設該狀態前使用它。

共同模式：

請求在設定程序進行到一半時遇上致命狀況（最常見的例子是記憶體不足），並異常終止。
請求範圍內的狀態只完成部分初始化，或在記憶體釋放後仍被引用。
清理程序，或同一工作程序處理的下一個請求，會信任該狀態。

研究人員表示，這可能導致記憶體洩露，以及以網絡工作程序的權限遠端執行程式碼。Wiz 表示，已證明可在 WordPress、Drupal 和 Joomla 上執行未經驗證的遠端程式碼，並指出受影響版本上的簡單「Hello World」指令碼也可能暴露於風險之中；應用程式本身不必有任何錯誤。

PHP 團隊表示，所有處理網絡請求的安裝都面臨風險：PHP-FPM、配合 mod_php 的 Apache、php-cgi、FrankenPHP 和 LiteSpeed。團隊認為 mod_php 的風險最高，並已證明有漏洞利用程式能在應用程式碼執行前觸發。

設計教訓：請求隔離只是一項假設

PHP 長久以來的吸引力在於其共享無狀態模型：每個請求都從乾淨狀態開始，並在結束時清除所有內容。長時間執行的工作程序令這個模型成為一項實作上的承諾，而非實際情況。程序會持續運作；每個請求能否表現得像是在全新環境中執行，取決於執行環境。

php2shell 展現了這項承諾在失敗路徑上失效時的情況。正常路徑會重設狀態，但請求在中途終止的路徑未能徹底重設狀態，於是下一個請求繼承了殘留狀態。

這種模式並非 PHP 獨有。只要工作程序、池、連線或 Agent 循環會重複使用，就應提出同一個問題：如果這個工作單位在最不理想的一行停止，下一個工作單位會看到甚麼？只在成功時才執行的清理並不是真正的清理。重試和部分完成背後也有同一個問題：復原始於瞭解失敗步驟留下了甚麼狀態。

按以下次序處理

1. 清點每個 PHP 執行環境，不要只檢查你的應用程式。Huntress 的清單是很好的起點：網頁伺服器、廠商設備、內置 php.exe 或 php-cgi.exe 的 Windows 軟件、cPanel 和 Plesk 等控制面板、容器基礎映像，以及 CMS 託管平台。在命令列執行 php -v，並不能證明 FPM 或 mod_php 正在運行；請檢查實際處理流量的 SAPI。

2. 優先修補面向互聯網的系統，然後重新啟動。上游修正版本：8.5.12、8.4.27、8.3.36、8.2.35。PHP 為 7.4、8.0 和 8.1 發布了最精簡的原始碼回補；這些分支已不再獲上游發布更新，因此請查詢你的發行版或 LTS 供應商。套件升級後若舊的 FPM 工作程序仍在運行，修補工作便尚未完成。

3. 把臨時設定視為部分緩解措施，PHP 亦明言如此。公告列出了一些緩解措施，供你在安排升級期間使用，並指出這些措施無法提供全面保護：

; Interim only — PHP says these do not fully prevent exploitation.
; Restart all workers after changing them.
session.upload_progress.enabled = 0

; Prefer php_admin_value in the FPM pool / Apache config so apps can't override.
post_max_size = 8M        ; 32M if you genuinely accept uploads

; PHP 8.5 only: blocks the confirmed fatal-backtrace path, nothing more.
fatal_error_backtraces = 0

公告亦建議使用 memory_limit=-1，並配合容器或 cgroup 限制，確保只會終止受影響的工作程序；此外，亦可在網頁伺服器或代理伺服器設定請求限制（解碼後大小、欄位數目、多部分表單部分數目、標頭數目、巢狀深度）。套用前請先考慮記憶體設定的改動：你是在以外部限制取代 PHP 自身的限制，因此外部限制必須確實存在，而且設定得夠嚴格。公告特別警告，不要使用 RLIMIT_AS 或 RLIMIT_DATA，因為它們可能觸發有漏洞的記憶體配置失敗。

在 php.ini、FPM pool 或伺服器設定中設定 session.upload_progress.enabled。公告指出，不要依賴 ini_set() 或 .user.ini，因為這項設定必須在解析請求前生效。

使用 display_errors、error_reporting 或 @ 隱藏錯誤並無幫助。問題在於致命錯誤留下的狀態，而非錯誤訊息有否顯示。

4. 把 WAF 當作防護層，而非修復方法。Cloudflare 在漏洞公開前約九小時部署了託管規則，並表示曾觀察到攻擊流量，以及針對這些規則的攻擊酬載變異；Cloudflare 亦明確指出，用戶仍須修補 PHP。到了星期三晚上，watchTowr、Patchstack、Hadrian 等已報告有人嘗試利用漏洞；watchTowr 表示，當時觀察到的嘗試均未成功，但預計這種情況不會持續太久。邊緣規則只能爭取時間，無法改變執行環境。

5. 留意相關證據，因為應用程式記錄可能線索不多。由於漏洞位於應用程式之下，你的框架記錄可能不會有太多資訊。研究人員建議留意以下訊號：

PHP 工作程序（php-fpm、php-cgi、httpd、apache2）啟動 sh、bash、python、curl、wget 或 nc
多部分表單請求後出現記憶體限制錯誤；大量 HTTP 500 錯誤
異常龐大或格式錯誤的 PHPSESSID Cookie
無法解釋的工作程序頻繁更替
網站根目錄出現新檔案、新增 cron 工作或新帳戶

如果在未修補的主機上發現上述任何情況，請先隔離主機並保存記錄，再重建主機。

修補時限如今更短

時間線上有兩個細節值得在規劃時留意。首先，Calif 表示於 1 August 使用 GPT-5.6 Sol 發現第一個問題，而 Wiz 則於 19 August 使用自己的工具和前沿模型獨立發現該問題；OpenAI 和 PHP 團隊均警告，相同的能力亦有助攻擊者構建漏洞利用程式。其次，10 October 的外洩令協調發布提前了一天。

我認為有用的結論不是恐慌，而是採取行動：根據 Cloudflare 的説法，本週從「修補程式已推出」到「觀察到漏洞利用嘗試」的時間幾乎為零。能在一小時內回答PHP 在哪裏執行、由誰負責，以及我們能多快重新啟動它的團隊，處境與要等到事故發生時才找出答案的團隊截然不同。

暴露程度也不等同於市場佔有率。廣泛引用的「70 per cent」數字，指的是 PHP 在網站中的佔比，而非可被利用的主機數量；據 Fortune 報道，Palo Alto Networks 最初估計有 22.6 million 個可能受影響的實例。漏洞利用的可靠程度會因版本、設定和記憶體配置而異。仍應修補，但應根據自己的資產清單規劃，而非根據標題。

來源

官方公告、已修正版本及緩解措施：PHP 安全公告，21 Oct 2026、GHSA-w8hw-w9fx-j79w (CVE-2026-109618)、GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
時間線及偵測指引：Huntress
已修正版本、受影響的 SAPI 及部分緩解措施：BleepingComputer
根本原因、發現時間線及指標：Wiz
邊緣防護及觀察到的攻擊流量：Cloudflare
漏洞利用嘗試：SecurityWeek
發現日期、受影響範圍估算及引述：Fortune
加拿大的下架行動：CP24

已於 2026 年 10 月 21 日晚上，根據 PHP 公告及上述來源核實事實。如指引有變，我會更新本文。