2026 年 10 月 21 日，PHP 專案發布緊急安全更新，修補 CVE-2026-109618 與 CVE-2026-109619。這兩個漏洞合稱 PHP2Shell，CVSS 4.0 評分皆為 9.2，可能讓未登入的攻擊者在伺服器上執行程式，或讀取 PHP 程序中的敏感資料。

PHP2Shell 這個名稱容易和 PHP web shell 混淆。Web shell 通常是攻擊者放進伺服器的後門程式；這裡的 PHP2Shell 指的是 PHP 核心的兩個記憶體安全漏洞，以及研究人員用來驗證漏洞的整合腳本。

這次研究也反映 AI 對資安工作的影響。PHP Foundation、Calif、OpenAI 與 Wiz 等團隊參與漏洞發現、驗證、修補測試及協調揭露，PHP 維護者則負責評估相容性並完成正式修補。相關過程可參考 PHP Foundation 的事件說明與 OpenAI 的協調揭露說明。

PHP2Shell 為什麼會影響不同網站系統

PHP2Shell 發生在 PHP 處理記憶體、錯誤與請求狀態的過程。

CVE-2026-109618 與記憶體不足時的處理有關。PHP 在中止請求時，部分內部資料可能尚未完成初始化，後續清理程序卻將它視為有效資料，造成記憶體損壞。

CVE-2026-109619 則涉及請求結束後殘留的內部狀態。原本屬於前一個請求的記憶體已經釋放，後續請求仍可能使用指向該區域的資料，形成 use-after-free 漏洞。

研究人員已在 WordPress、Drupal 與 Joomla 環境中展示未經驗證的遠端程式執行，也展示了不依賴特定應用程式的記憶體資料洩漏。這些網站系統是驗證漏洞的代表環境；只要網站底層使用受影響的 PHP，簡單的自建程式同樣需要檢查。完整的技術範圍可參考 PHP2Shell 研究說明。

攻擊者若成功執行程式，可能讀取網站資料、修改內容、植入後門，並利用伺服器持有的權限接近其他系統。記憶體洩漏則可能暴露資料庫密碼、登入權杖、API 金鑰或憑證，而且伺服器上未必會出現新的惡意檔案。

PHP 官方安全公告指出，所有對外處理網頁請求的 PHP 安裝都在檢查範圍內，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 與 LiteSpeed；其中 Apache mod_php 已展示在網站應用程式開始執行前觸發攻擊的路徑。因此，更新 WordPress 核心、佈景主題或外掛，並不會同步更新伺服器上的 PHP。

如何找出需要更新的 PHP 執行環境

一台伺服器可能同時有命令列 PHP、PHP-FPM、Apache 模組，以及不同網站使用的容器映像。正式站、測試站、舊版管理介面與背景處理服務，也可能各自使用不同版本。

盤點時應從所有能接收網路請求的網站與服務開始，記錄：

• PHP 的實際版本與套件來源
• 使用 PHP-FPM、mod_php、CGI 或其他執行方式
• 對外網路入口及反向代理設定
• 所屬容器映像、虛擬主機或代管服務
• 維護負責人與重新啟動方式

在終端機執行 php -v 通常只會顯示命令列版本。網站可能由另一個 PHP-FPM pool、Apache 模組或容器處理，因此還要查看實際服務設定、執行程序和部署映像。

PHP 專案於 2026 年 10 月 21 日發布的第一批修補版本如下：

Linux 發行版與長期支援供應商可能將修補程式回補到不同的套件版號。這種情況應查閱供應商安全公告，確認套件已包含兩個 CVE 的修補。

PHP 8.1 與更早的分支已停止由 PHP 專案提供一般安全更新。仍在使用這些版本的企業，需要確認作業系統或 LTS 供應商是否提供回補，並安排遷移到仍受支援的版本。

代管網站的使用者可以直接向供應商確認三件事：實際執行的 PHP 版本、PHP2Shell 修補所對應的套件版本，以及服務是否已在更新後重新啟動。網路上出現的掃描器與 PoC 品質不一，依版本和供應商公告盤點，較容易留下可驗證的修補紀錄。

如何確認修補已經在正式環境生效

安裝套件或建立新的容器映像後，原本執行中的 PHP worker 可能仍載入舊程式碼。正式處置需要完成更新、重新啟動及驗證。

採用 PHP-FPM 的環境，要重新啟動相關 pool；使用 mod_php 的環境，要重新啟動 Apache；容器化環境則要重新建置並部署使用修補套件的新映像。佇列處理器及其他長時間執行的 PHP 程序，也要一併更新。

服務恢復後，應從執行中的環境重新確認版本，並測試登入、檔案上傳、Session、API 與背景工作等主要功能。若公司使用多台主機或自動擴展，還要確認舊映像已退出部署，不會在擴容時重新出現。

PHP 官方於 2026 年 10 月 23 日另外發布 Session upload progress 說明。使用特定 Session 序列化設定的少數應用，可能需要暫時關閉 session.upload_progress.enabled，直到下一次常規修補發布。

若更新需要等待相容性測試，PHP 官方也列出降低特定攻擊路徑的方法，包括限制請求大小、停用 Session upload progress，以及調整記憶體限制。這些變更可能影響上傳、穩定性與效能，適合用來爭取部署更新的時間；完整處置仍要落在正式安全版本。

WAF、CDN 或代管商規則也能攔截部分已知請求型態，但 PHP2Shell 包含多種觸發路徑，規則覆蓋範圍會隨產品與設定不同。

修補後為什麼還要調查是否曾遭入侵

美國 CISA 在 2026 年 10 月 26 日將兩個 PHP2Shell 漏洞加入 Known Exploited Vulnerabilities 目錄，表示漏洞已有實際遭利用的證據。對外公開且曾執行受影響版本的主機，應把更新與入侵調查放在同一份處理計畫中。相關紀錄可查閱 CISA KEV 官方資料。

調查可以先保存反向代理、Web Server、PHP 錯誤、程序、容器與網路連線紀錄，再依時間線檢查：

• 異常或過大的 multipart 請求
• 異常的 PHP Session cookie
• 集中的記憶體錯誤與 HTTP 500 回應
• PHP worker 無法解釋的崩潰或重新啟動
• 網站目錄與系統檔案的非預期變更
• PHP 程序啟動命令列工具或建立對外連線
• 新增的帳號、排程工作與長駐程序

CISA 已提供 PHP2Shell 偵測規則，同時標示部分條件可能產生中高程度的誤報，需要依環境調整並由分析人員判讀。

沒有發現惡意檔案，也不足以排除資料外洩。PHP2Shell 的記憶體揭露路徑可能讀到密碼、權杖、API 金鑰與憑證。當主機曝險時間長、出現可疑紀錄，或已有入侵證據時，應盤點 PHP 程序能接觸的秘密資料，輪替相關憑證並撤銷既有登入 Session。

確認主機遭到控制後，還要檢查攻擊者是否建立後門、取得其他帳號或移動到內部系統。從可信映像重新建立主機，再恢復經過確認的資料，通常比在原主機上逐一刪除可疑檔案更容易重新建立信任；進行處置前則應先保存調查所需的證據。

PHP2Shell 的修補工作最後應留下三項可查證結果：所有 PHP 執行環境的版本清單、更新後實際運作版本，以及曝險期間的調查與憑證處理紀錄。這三項結果能讓管理者確認漏洞與既有影響都已納入處理。