PHP2Shell 修補與驗證指南：cPanel、CloudLinux、LiteSpeed 更新實務

PHP2Shell 涉及 CVE-2026-109618 與 CVE-2026-109619，兩項漏洞分別與記憶體不足時的處理，以及失效內部狀態有關，可能造成未經身分驗證的遠端程式碼執行。問題位於 PHP 核心，因此網站系統、外掛或應用程式更新，無法直接取代 PHP 環境的修補。若需要先掌握事件背景與企業應對方向，可參閱 PHP2Shell 漏洞與網站影響說明。

依據 PHP 官方安全公告，處理網站請求的 PHP 環境均應評估，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 與 LiteSpeed。官方於 2026 年 10 月 21 日發布 PHP 8.5.12、8.4.27、8.3.36 與 8.2.35，修補這兩項漏洞。

對技術人員而言，應先確認網站請求實際經過哪一套 PHP，再確認該環境已取得適用修補、載入新程序並完成驗證。有防火牆、網站仍可使用，或暫時沒有異常紀錄，都不能單獨作為修補完成的證明。

EA-PHP：由 EasyApache 套件體系管理的 PHP

EA-PHP 是 cPanel EasyApache 使用的 PHP 套件系列。技術人員應確認套件實際由哪個來源提供，再依該供應商的公告核對修補狀態，避免將不同來源的版本資訊直接混用。

MultiPHP Manager 可管理網域的 PHP 與 PHP-FPM 設定，但全域預設值、網域個別設定與繼承狀態可能不同。查核時應逐一確認目標網域，不能只查看主機預設版本。

Alt-PHP：常與 CloudLinux PHP Selector 搭配的 PHP

Alt-PHP 是 CloudLinux 提供的另一套 PHP 套件系列，常搭配 PHP Selector 使用。環境中可能同時安裝 EA-PHP 與 Alt-PHP，因此更新其中一套，並不代表另一套也已完成處理。

CloudLinux 與控制台的整合涉及使用者環境及選擇器設定。當不同管理介面顯示不一致時，應交叉檢查網域處理方式、使用者選擇及網站端結果，不能直接認定其中一個畫面就是最終答案。CloudLinux 控制台整合文件

系統原生 PHP、命令列與工具內部 PHP

作業系統本身提供的 PHP，可能用於排程或命令列工作；管理工具也可能使用自己的 PHP。這些環境應依實際用途分別盤點，不能直接套用網站端的判斷結果。

其中，php -v 只代表當次命令所執行的 PHP。它可以協助檢查命令列環境，卻無法單獨證明網站請求使用同一套執行檔、設定或套件。

PHP 版本號沒有改變，是否代表 PHP2Shell 尚未修補？

不一定。供應商可能採用安全回補，也就是把漏洞修正套用至既有套件，保留原本的上游版本號，再透過套件修訂版區分。

CloudLinux 官方修補狀態頁說明，部分早期修補套件採用回補方式，後續才發布與 PHP.net 版本號一致的套件。因此，單看較舊的 PHP 版本字串，可能誤判已取得回補修正的環境。

判斷時應一起核對：

• 套件名稱、供應商及來源。
• 完整套件版本與修訂版。
• 適用的作業系統與發行版本。
• 官方安全公告、修補紀錄或套件變更紀錄。

查核變更紀錄時也要注意適用範圍。部分套件可能以重新基於新版發布的方式記錄更新，未逐一列出 CVE 編號，因此搜尋不到漏洞編號，仍需回到官方版本對照確認。

技術紀錄建議寫成「已依供應商公告確認指定套件包含本次修補」，並保留核對依據，避免只留下「PHP 版本看起來正常」的結論。

① 確認備份、處理範圍與回復方式

更新前應確認必要的網站檔案、資料庫與設定備份可用，並掌握哪些服務可能受到變更影響。對具有交易、會員或排程工作的網站，也應確認更新期間的操作安排。

回復方案需要兼顧安全狀態。如果因相容性問題回到尚未修補的套件，仍會重新暴露漏洞風險；應同步評估限制存取、改用已修補套件或其他處理方式。

② 分別盤點各套 PHP 與使用中的網站

將 EA-PHP、Alt-PHP、系統原生 PHP，以及其他獨立部署的 PHP 分開列出，再對應到實際網站與服務。盤點範圍應涵蓋仍對外開放的測試站、子網域及其他入口。

已安裝但暫未使用的版本，也應列入管理紀錄，避免日後切換版本或恢復舊站時，重新啟用未處理的環境。

③ 查詢更新並檢視交易內容

更新前先確認可用套件、來源與相依性變更。若預覽結果包含非預期移除、大量降版、來源切換或無法解決的相依問題，應先確認原因。

「沒有可更新套件」也不等於已完成修補，仍需排查套件庫狀態、快取、版本鎖定及來源是否適用。操作方式應依供應商當下公告安排，避免直接套用其他發行版本的指令。

④ 完成更新，確認使用者環境同步

套件更新後，若環境使用 CageFS，應依整合方式確認使用者隔離環境是否同步取得必要檔案與設定。不能只確認主機端已更新，就略過使用者環境的實際結果。

CloudLinux 文件說明，安裝軟體或調整系統配置後，需按其要求更新 CageFS；更新完成仍應以實際使用者與網站環境驗證。

⑤ 重新載入相關程序，再驗證網站

套件寫入磁碟，不代表所有既有工作程序已重新載入。應依 PHP-FPM、mod_php 或 LiteSpeed 等實際模式，安排對應的程序更新。

這些步驟應留下執行時間、套件結果與驗證紀錄。修補狀態需要由後續檢查確認，不能只以更新工具顯示成功作結。

在 LiteSpeed Detached PHP 模式下，PHP 工作程序具有獨立的生命週期。重新啟動網頁伺服器，不能直接作為所有 PHP 程序都已重新載入的證明。

LiteSpeed 官方文件提供帳號與伺服器層級的 Detached PHP 重啟方式，部分機制會在後續請求使用對應處理器時，逐一重新啟動。因此，操作完成後仍需確認涵蓋範圍，以及舊程序是否已退出服務。

技術人員應檢查程序的啟動時間、執行檔對應及更新後的請求結果。若需要立即停止尚未載入修補的程序，也應考量進行中的交易、上傳與長時間工作，選擇符合風險與營運需求的處理方式。

PHP 設定變更同樣需要留意程序狀態。cPanel 支援文件指出，LSAPI Detached 模式下，相關程序需要重啟，才能取得新的 php.ini 路徑或設定。

第一層：套件是否包含修補

依供應商公告核對套件完整版本、來源與適用平台，確認本次修補已安裝。這一層回答的是「磁碟上的套件是否符合修補要求」，尚未證明網站已使用它。

若環境有多套 PHP，應分別保留確認結果，避免用其中一套套件的更新狀態，代表整台主機或所有網站。

第二層：執行中的程序是否載入更新

檢查實際服務中的 PHP 程序，確認執行檔對應、啟動時間及重啟結果。必要時也應留意程序是否仍持有已被替換的舊檔案或函式庫。

程序名稱相同，並不代表內容相同；只看到程序仍在運作，也無法證明它已載入新套件。應將程序結果與套件更新時間交叉核對。

第三層：網站請求是否使用預期的 PHP

從受保護的管理介面或短期診斷方式，確認目標網域實際回報的 PHP 版本、SAPI 與必要設定。測試請求應確實到達 PHP，避免把快取或靜態回應當作驗證結果。

網站端版本字串可以協助對應環境，但不能單獨證明安全回補狀態；仍需與套件及程序證據串接。若有多個服務節點或不同處理器，也應涵蓋各個可能接收請求的環境。

第四層：功能與紀錄是否正常

完成更新後，檢查登入、後台、表單、上傳、資料庫操作及相關串接，並觀察是否出現新的錯誤。排程與命令列工作若使用另一套 PHP，也需要另外驗證。

功能正常可以證明更新後的操作結果，卻無法取代前三層的修補確認。同樣地，修補完成也不代表已排除過往入侵，若存在可疑紀錄，仍應另行調查。

在此次處理經驗中，管理介面資訊與網站實際執行結果不一致，是需要特別交叉確認的情況。控制台可能顯示某個網域的預設或指定版本，網站請求卻因繼承、使用者選擇或處理器整合方式，由另一套 PHP 執行。

遇到這種情況，應依序確認網域設定、PHP Selector 選擇、處理器對應，以及網站端實際結果，再回頭核對套件修補。不能只修改其中一個下拉選單，就認定網站已經切換完成。

這個案例的重點，是建立「網域 → 處理器 → 執行檔與程序 → 套件來源」的對應關係。對應關係清楚後，後續更新、問題排查與版本升級也更容易驗證。

網站端診斷應只輸出此次需要核對的欄位，例如 PHP 版本、SAPI 與指定設定的有效值，並限制存取範圍。完整 phpinfo() 可能揭露模組、環境變數與路徑，不適合長期公開。

診斷頁面應由授權人員使用，避開不必要的網站快取，確認測試涵蓋的網域與節點，完成後移除。對外提供的報告則可記錄驗證時間、結果與涵蓋範圍，省略內部路徑、帳號、IP 及完整設定輸出。

若檢查方式只取得 HTTP 回應標頭或公開版本資訊，應標明它僅能作為初步盤點，無法證明供應商安全回補、程序載入及內部設定狀態。

PHP 官方於 2026 年 10 月 23 日另外發布 Session upload progress 說明，涉及 CVE-2026-115560。風險條件包含特定 Session 序列化設定、應用程式執行期間切換處理方式，以及上傳進度功能仍啟用等組合；不能解讀為所有已更新網站都具有相同風險。

截至 2026 年 10 月 25 日，PHP 官方後續公告建議，於下一次例行修正版前將 session.upload_progress.enabled 設為 0；不會在執行期間切換序列化處理方式的應用程式，可依公告判斷。這項後續說明不代表原先兩項核心修補被撤回。

實務上，設定檔沒有寫出某個項目，不代表該功能已停用。若只搜尋既有設定並取代，可能因找不到該行而沒有完成任何變更；修改後應重新載入適用程序，再從網站執行環境核對有效值。

原本兩項 PHP2Shell 修補與後續 Session 項目，應分開記錄處理狀態，避免用「已更新 PHP」概括所有後續確認。

供應商為舊分支提供本次回補，不代表該分支恢復一般官方支援，也不代表所有未來問題都會持續獲得修正。企業仍應確認支援來源、期限及後續升級計畫。

以 PHP 8.2 為例，官方安全支援將於 2026 年 12 月 31 日結束。選擇升級目標時，應同時考慮支援期限與程式相容性，而非只完成本次修補就停止規劃。

舊網站升級評估應涵蓋登入驗證、資料庫存取、圖片處理、表單、金流、排程及第三方套件。必要時可先調整程式或更新元件，再分階段遷移，降低一次變更造成的影響。若既有系統包含自製後台或特殊流程，也可依相容性評估結果，規劃必要的程式重構與客製化程式開發，讓升級後的環境持續支援實際業務。

若主機使用雲端虛擬主機租賃服務，也應確認供應商負責的環境更新範圍，以及網站程式相容性由誰處理，讓兩端工作相互銜接。

PHP 7.4 顯示舊版本，是否代表沒有修補？

不能只依版本字串判定。若使用供應商維護的回補套件，需核對完整套件版本與公告；若是未套用修正的原始舊版本，則不能視為已處理。另須確認舊分支後續支援與升級安排。

為什麼命令列與網站顯示不同的 PHP 版本？

命令列與網站可能使用不同執行檔、環境設定及處理器。應分別確認用途與來源，將網站請求對應至實際 PHP，而非只採用命令列結果。

更新套件後，是否還需要重新啟動 PHP？

需要依執行模式確認相關程序已重新載入。尤其是長時間運作的工作程序與 Detached PHP，不能只以套件安裝完成或網頁伺服器已重啟作為依據。

關閉上傳進度功能，會影響圖片上傳嗎？

session.upload_progress.enabled 管理的是 Session 上傳進度追蹤，與是否允許檔案上傳屬於不同功能。一般上傳流程不會因此直接被關閉，但若網站依賴該機制顯示進度，相關功能需另行測試。

修補完成，是否表示網站沒有遭入侵？

不是。修補確認與入侵調查處理不同問題。若發現異常檔案、帳號或可疑請求，仍需保存紀錄並評估調查，不能以更新成功取代排查。

如何把 PHP2Shell 修補納入持續網站維護？

此次處理應留下可追溯紀錄，包括公告核對日期、套件來源、完整版本、程序更新結果、網站驗證範圍與功能檢查。後續再依新公告補充設定與版本的確認狀態。

日常維護也應持續追蹤套件支援、備份與還原驗證、網站系統及第三方元件更新。當環境或網站程式變更時，重新確認重要設定與執行結果，避免舊紀錄被當作目前狀態。企業也可進一步了解網站維護內容與服務分工，將此次修補經驗納入定期檢查與長期升級安排。

建議將處理結果明確區分為「已確認」、「待確認」及「不適用」，並註明證據範圍。這比單一的「安全／不安全」標籤，更能協助技術交接與後續管理。