漏洞編號：CVE-2026-109618、CVE-2026-109619
資安評級：CVSS v4.0 9.2 / 10（Critical 極度危險）
影響範圍：PHP 5.4.0 至當前未修補之所有 PHP 版本（包括 PHP 8.2、8.3、8.4）
威脅類型：未授權遠端程式碼執行（Remote Code Execution, RCE）
1. 漏洞背景與事件概述
PHP 官方團隊與多家全球資安機構（包含 watchTowr、Sansec 等）緊急揭露並提前公開了代號為 「PHP2Shell」 的兩個嚴重核心漏洞。
該漏洞原本處於保密揭露階段（Embargo），但因相關細節與自動化利用腳本意外在外洩論壇與社群流出，威脅情報機構警告全球自動化掃描與大規模攻擊預計在極短時間內爆發。PHP 官方隨即將安全性更新排程大幅提前至 2026 年 10 月 21 日 14:00 UTC（台灣時間 22:00） 緊急發布。
2. 漏洞成因與運作原理
核心元兇：session.upload_progress 的處理缺陷
這起漏洞直指 PHP 核心對於 RFC 1867（multipart/form-data 上傳規範）的底層解析機制：
- 預設開啟的古老功能：自 PHP 5.4 引入的
session.upload_progress.enabled 預設值為 1（On）。
- 生命週期前置觸發：當客戶端向伺服器發送帶有
PHP_SESSION_UPLOAD_PROGRESS 參數的 Multipart 請求時，PHP 在執行任何使用者業務程式碼（如 WordPress 的 index.php）之前，底層 C 語言回呼函式（如 php_session_rfc1867_callback）就會強制介入，解析請求並初始化 Session 結構寫入磁碟。
- 記憶體指標缺陷（Use-After-Free 等問題）：外洩分析顯示，在特定特製的多段資料解析或資料重載過程中，存在記憶體指標未妥善釋放或邊界檢驗瑕疵，使未經身分認證的遠端攻擊者得以透過精心構造的二進位請求污染記憶體空間，進而劫持執行流達成任意程式碼執行（RCE）。
3. 為什麼影響如此巨大？
- 應用層程式碼無法自防：
因為漏洞觸發在 PHP 引擎載入請求的瞬間，網站內部寫得再安全的程式碼、WordPress 安全外掛（如 Wordfence 等）都無法攔截，因為外掛程式碼根本還沒開始執行。
- 無需上傳功能即可打穿：
伺服器即使只是個靜態的 PHP 首頁、完全沒有任何檔案上傳入口，只要攻擊者主動將請求偽造成 multipart/form-data 傳送給任意 .php 端點，底層漏洞邏輯就會被強制調用。
- 舊版本已無官方修補：
PHP 官方維護清單中僅針對當前支援的分支（PHP 8.2、8.3、8.4 及後續開發版）提供官方緊急補丁。已進入 EOL（生命週期終止）的 PHP 5.x、7.x、8.0、8.1 不會收到官方更新，暴露極高風險。
4. 緊急應對與處置SOP
步驟一：升級 PHP 至官方修補版本（最根本解法）
請立即確認系統套件管理器或 Docker 映像檔，第一時間更新至官方釋出的修復版本：
步驟二：立即套用臨時緩解措施（未更新前必做）
在官方套件尚未同步至鏡像站、或需要評估停機時間時，請立即關閉 session.upload_progress。
1. 修改全域 php.ini
找到伺服器上執行的 php.ini（通常在 /etc/php/8.x/fpm/php.ini 或 /etc/php.ini）：
; 將原先的 1 改為 0 或 Off
session.upload_progress.enabled = 0
2. 強制鎖定 PHP-FPM Pool（防止目錄層被覆寫）
若使用 PHP-FPM，請編輯對應的 Pool 配置檔（如 /etc/php/8.x/fpm/pool.d/www.conf），加入 php_admin_flag：
php_admin_flag[session.upload_progress.enabled] = off
3. FrankenPHP / Caddyfile
若使用 FrankenPHP，請在全域選項區塊加入：
{
frankenphp {
php_ini {
session.upload_progress.enabled 0
}
}
}
重要：修改配置後務必重新載入或重啟服務：
sudo systemctl reload php*-fpm
# 或重啟 Web 伺服器
步驟三：Web 伺服器 / 反向代理層防護（可選強化）
若網站完全不具備使用者檔案上傳需求，可在 Nginx / Apache 層直接拒絕帶有 Multipart 的請求，使惡意封包在進入 PHP 之前就被丟棄：
Nginx 範例：
# 針對無上傳功能的站點直接攔截 Multipart Content-Type
if ($http_content_type ~* "multipart/form-data") {
return 403;
}
若有特定 API 需要上傳檔案，建議僅在對應的 location 放行，其餘全域阻擋。
5. 常見問題（FAQ）
Q：關閉 session.upload_progress.enabled 會弄壞我的 WordPress 嗎？
A：完全不會。 WordPress 核心自架構設計起就採用無狀態機制，媒體庫上傳進度是依靠前端 HTML5 API（XMLHttpRequest.upload.onprogress）即時計算，從未依賴過 PHP 原生 Session 進度條。停用此選項對 WordPress 後台、媒體庫與外掛運作零影響。
Q：只要關閉 session.upload_progress.enabled 就能高枕無憂了嗎？
A：不能。 關閉此設定僅能封鎖已知外洩利用鏈（Reported Exploit Path），由於該漏洞牽涉到 Multipart 底層解析機制，官方明確指出「唯有將 PHP 引擎核心升級至修復版本才是唯一完整解法」。
6. 應變行動清單（Checklist）
- [ ] 盤點全伺服器目前運行的所有 PHP 版本（特別注意 Docker、舊式沙盒環境）
- [ ] 優先在測試/正式機修改
session.upload_progress.enabled = 0 並重啟 PHP-FPM
- [ ] 檢查並更新至 2026-10-21 發布之 PHP 安全釋出版本
- [ ] 針對仍運行 PHP 8.1 及更舊版本之主機，規劃停機遷移或向作業系統發行商尋求 Backport 補丁
- [ ] 檢視系統稽核紀錄（auditd / Web Access Log），過濾異常的大量 POST Multipart 異常請求