部落格來源網址：PHP2Shell: Two critical PHP vulnerabilities and how to respond
PHP2Shell：兩項重大 PHP 漏洞與應變方式
研究發布日期：2026 年 10 月 21 至 22 日
PHP 執行環境近期揭露兩項重大漏洞，促使整個 Web 應用程式生態系緊急展開資安應變。2026 年 10 月 21 日公開的 CVE-2026-109618 與 CVE-2026-109619，統稱為 PHP2Shell，涉及 PHP 內部記憶體處理機制，可能讓未經身分驗證的攻擊者遠端執行程式碼（Remote Code Execution，RCE）。
兩項漏洞的通用漏洞評分系統（CVSS v4.0）分數均為 9.2，屬於重大風險。不同於依賴應用程式業務邏輯缺陷的漏洞，這兩項問題存在於 PHP 本身。即使網站或服務的應用程式程式碼遵循安全開發實務，仍可能面臨暴露風險。
對資安團隊而言，當務之急是找出受影響的 PHP 執行環境、在必要時降低暴露風險、部署已修補版本，並確認補救措施是否成功。
Vicarius 也提供兩項社群腳本，協助企業應變：
這些資源可協助漏洞偵測與風險降低，但不能取代安裝 PHP 官方安全更新。
什麼是 PHP2Shell？
PHP2Shell 是近期揭露的兩項 PHP 核心執行環境記憶體安全漏洞的統稱。
這兩項漏洞透過 Wiz Research 與 PHP 資安團隊共同參與的協調研究程序揭露。Google 也說明，AI 輔助漏洞探索及修補驗證在這項研究過程中所扮演的角色。
兩項問題都涉及 PHP 在處理 Web 請求期間，未能安全管理內部執行環境的記憶體與狀態。
在特定條件下，攻擊者可以操控 PHP 處理請求的方式，進而可能導致記憶體損毀、資訊洩露，或執行未經授權的程式碼。
關鍵差異在於，利用這兩項漏洞不需要應用程式本身存在不安全的 PHP 函式。攻擊面涵蓋負責處理請求的 PHP 執行環境，因此基礎架構層級的漏洞補救格外重要。
PHP 資安團隊認為，使用 mod_php 的 Apache 部署環境具有目前已證實的最高風險，但其他 PHP 執行環境也必須緊急檢視。
CVE-2026-109618：記憶體不足處理異常導致遠端程式碼執行
CVE-2026-109618 是一項重大記憶體損毀漏洞，涉及 PHP 處理記憶體不足情況時的運作方式。
當 PHP 遇到記憶體配置失敗時，程式執行可能中止，而部分內部請求資料結構仍處於尚未完全初始化的狀態。
在後續清理程序中，PHP 執行環境可能錯誤地將無效的內部資料視為合法資料，進而產生可能遭利用的記憶體損毀情況。
為什麼這個問題值得關注？
記憶體耗盡不一定只會發生在異常工作負載下。對外提供服務的 Web 應用程式，經常需要處理請求、表單資料、檔案上傳，以及其他可能影響資源消耗的輸入內容。
如果攻擊者能夠引導程式執行進入存在漏洞的失敗處理路徑，就可能觸發危險的清理行為。
若成功利用漏洞，攻擊者可能以受影響 PHP 程序的權限遠端執行程式碼。
如何緩解 CVE-2026-109618？
安裝已修補的 PHP 版本，是建議採取的正式補救措施。
如果無法立即安裝更新，PHP 官方安全公告提供了可降低特定攻擊路徑暴露風險的暫時性措施，包括：
- 在適當的管理層級設定
memory_limit=-1，移除 PHP 可設定的記憶體限制所造成的失敗路徑，但仍須注意底層記憶體配置失敗的情況依然可能發生。 - 在 PHP、Web 伺服器或 Proxy 層限制請求與檔案上傳大小。
- 使用容器或 cgroup 資源限制，作為資源使用與服務可用性的控制邊界。
- 確認應用程式層級的設定覆寫，不會使預期的防護措施失效。
這些措施可能影響應用程式行為與資源使用量，因此部署前應先完成測試。
Vicarius 社群資源： CVE-2026-109618 PHP2Shell 緩解腳本
在正式環境部署前，應先審查腳本、確認腳本的適用前提符合實際環境，並驗證執行效果。暫時性緩解措施不代表漏洞已完全消除。
CVE-2026-109619：全域狀態殘留導致遠端程式碼執行
CVE-2026-109619 涉及另一項 PHP 執行環境的記憶體管理弱點。
當屬於特定請求的內部狀態所依賴的記憶體已被釋放，但該狀態仍可被存取時，就可能產生此漏洞。
當同一個 PHP 工作程序（Worker）處理後續請求時，可能在正常初始化程序重新建立狀態之前，先遇到這些殘留的內部狀態。
這會形成記憶體釋放後使用（Use-After-Free）漏洞，可能導致記憶體損毀與遠端程式碼執行。
為什麼持續運作的 PHP 工作程序，使漏洞偵測更加重要？
PHP 部署環境通常使用工作程序處理多個請求。
重複使用工作程序有助於提升效能，但也讓不同請求之間是否能正確隔離變得格外重要。
如果內部狀態在原本應結束的生命週期之後仍然存在，後續請求就可能接觸到理應已不存在的資料。
這也是漏洞偵測不能只依賴應用程式原始碼檢查的原因之一。團隊還需要掌握正式環境實際使用的 PHP 執行版本與部署組態。
如何應對 CVE-2026-109619？
PHP 官方建議升級至已修補版本。
針對無法立即更新的環境，官方安全公告指出，下列設定措施可阻斷部分已確認的攻擊路徑：
- 在請求解析開始前即生效的組態層級，設定
session.upload_progress.enabled=0。 - 變更上述設定後，重新啟動受影響的 PHP 工作程序。
- 如果使用 PHP 8.5，設定
fatal_error_backtraces=0，並重新啟動工作程序，以阻斷已確認的致命錯誤回溯攻擊路徑。 - 將這些措施視為暫時性的風險降低方式，而非全面防護。
由於仍可能存在其他漏洞利用變化形式，因此即使成功調整組態，也不能據此認定仍有漏洞的 PHP 執行環境已經安全。
Vicarius 社群資源： CVE-2026-109619 PHP2Shell 偵測腳本
利用偵測結果辨識可能受影響的系統、安排調查優先順序，並支援後續補救規劃。即使腳本回傳陰性結果，也不能將其視為漏洞絕對無法遭利用，或系統從未遭入侵的確切證明。
哪些 PHP 版本受到影響？
這次揭露的漏洞涉及可追溯至 PHP 5.4 的版本，包括已停止支援的舊版本，以及先前仍屬現行版本的分支。
PHP 專案於 2026 年 10 月 21 日發布以下已修補版本：
| PHP 版本分支 | 首個已修補版本 |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
| PHP 8.1 及更早版本 | 無標準官方上游安全更新版本；應升級或取得經確認且受供應商支援的安全更新 |
使用 Linux 發行版套件的組織，應確認該發行版供應商的安全公告，而不是只依賴顯示的 PHP 上游版本號判斷。部分長期支援版本的供應商，會將安全性修補程式回溯移植（Backport）至既有套件版本。
對於已停止支援的 PHP 版本，應優先規劃遷移至仍受維護的版本。
哪些系統暴露於 PHP2Shell 風險？
PHP 官方安全公告指出，下列多種執行環境都需要檢視：
- 使用 mod_php 的 Apache HTTP Server 部署環境
- 在 Nginx 或 Apache 後端運作的 PHP-FPM 環境
- 使用 php-cgi 的部署環境
- 以 FrankenPHP 建置的應用程式
- LiteSpeed PHP 部署環境
- 容器化及雲端託管的 PHP 服務
系統使用 PHP，並不代表每一種部署方式都會以相同方式遭到利用。實際暴露風險取決於執行環境版本、執行模式、組態設定、請求處理方式，以及其他技術條件。
然而，這兩項漏洞存在於應用程式層以下的執行環境。
即使應用程式維護良好，只要底層 PHP 執行環境存在漏洞，仍可能面臨暴露風險。
因此，組織應檢視基礎架構與執行環境清冊，而不能只依賴應用程式層級的漏洞評估。
PHP2Shell 的實務補救流程
應對重大漏洞，不能只停留在掃描器識別出 CVE 的階段。
資安與基礎架構團隊必須將漏洞情資轉化為適用於各環境的安全變更，並在執行後確認變更確實生效。
步驟一：盤點所有 PHP 執行環境
盤點實體伺服器、虛擬機器、容器、應用程式映像檔與託管服務中的 PHP 安裝情況。
檢查正式環境、測試環境、可從不受信任網路存取的開發環境，以及可能使用不同 PHP 執行檔或執行環境的系統。這些系統所使用的 PHP 版本，可能與命令列介面顯示的版本不同。
例如，可以先使用下列指令：
php -v
這項指令會顯示目前呼叫的 PHP 命令列介面（CLI）執行檔版本，但不一定代表 Web 伺服器或 PHP-FPM 工作程序實際使用的版本。
完整的資產探索必須涵蓋真正負責處理請求的 PHP 執行環境。
步驟二：優先處理對外提供服務的應用程式
先從處理不受信任 Web 請求的系統著手，尤其是 PHP 官方安全公告指出具有最高風險的部署組態。
優先順序評估應考慮：
- 服務是否可透過公開網路存取
- 已安裝的 PHP 版本與供應商修補狀態
- 部署模式及已確認的攻擊路徑
- 應用程式是否能存取敏感資料或其他相連系統
- 現有安全控制措施，以及可採取的暴露風險降低方式
避免只使用 CVSS 分數決定漏洞補救順序。即使兩個系統受到相同漏洞影響，其實際營運風險與業務風險仍可能不同。
步驟三：執行適當的偵測檢查
資安團隊可以利用漏洞清冊、組態檢查、供應商安全公告比對，以及專門設計的偵測腳本，判斷哪些系統需要進一步處理。
Vicarius 針對 CVE-2026-109619 提供一項社群資源：
在依據腳本結果進行判斷前，應先確認腳本支援的作業系統、所需權限、運作邏輯及輸出內容。
記錄可能存在的暴露風險、受影響資產，以及偵測方法的限制。
步驟四：套用安全更新或暫時性緩解措施
最優先的行動，是安裝適當的已修補 PHP 版本，或經確認已回溯移植安全修補程式的供應商更新。
若安裝更新需要額外測試或等待維護時段，團隊可評估影響範圍明確的暫時性控制措施。
針對 CVE-2026-109618，應搭配 PHP 官方安全公告，一併檢視 Vicarius PHP2Shell 緩解腳本。
涉及 PHP 資源處理的變更，應以貼近實際應用程式工作負載與資源限制的條件進行測試。
暫時性防護措施能在正式修補期間協助降低風險，但不應無限期取代正式補救作業。
步驟五：驗證補救結果
軟體更新工作顯示已完成，不代表正在執行的應用程式就一定受到保護。
部署更新後，應確認：
- 已安裝的 PHP 執行環境包含適當的修補程式，或供應商回溯移植的安全更新。
- 對外服務的 PHP 工作程序已使用更新後的執行環境。
- 必要時，容器或應用程式服務已完成重新部署。
- 應用程式功能與服務可用性仍維持正常。
- 暴露風險或漏洞檢查結果，不再識別出相關的未修補 PHP 執行環境。
保存已安裝修補程式及實際執行組態的佐證資料。
這能更清楚區分「已嘗試執行補救措施」與「已驗證的資安成果」。
為什麼 PHP2Shell 修補也是一項曝險管理挑戰？
PHP2Shell 漏洞揭露反映了資安團隊熟悉的難題：發現重大漏洞的速度，可能遠快於在所有受影響系統中安全降低風險的速度。
單一組織可能透過不同的 Linux 發行版、雲端服務、容器、應用程式團隊及舊有平台執行 PHP。
每種環境可能需要不同的更新機制或維護程序。
部分系統可以直接更新，其他系統則需要相容性測試、應用程式負責人核准，或先行採取暫時性的暴露風險降低措施。
因此，漏洞補救不只是漏洞情資問題，也是跨團隊協作問題。
最有效的應變方式，應串接以下四項活動：
探索（Discovery）： 確認受影響軟體實際運作於哪些系統。
優先排序（Prioritization）： 判斷哪些存在漏洞的系統造成最大的暴露風險。
補救（Remediation）： 部署受支援的更新，以及適當的暫時性控制措施。
驗證（Validation）： 確認預期的變更已生效，並掌握剩餘風險。
對需要管理大量端點與伺服器的組織而言，這種方法有助於縮短從發現重大漏洞，到取得暴露風險已獲處理之佐證的時間。
Vicarius 如何支援漏洞補救？
Vicarius 將漏洞補救視為一項實際維運流程，結合軟體與漏洞可視性，以及不同的補救方式。
依據受影響系統及可用的補救選項，資安團隊可能需要部署修補程式、執行已核准腳本，或在正式修補準備完成前，先採取暫時性的補償性控制措施。
PHP2Shell 漏洞事件說明了，為什麼這些方法需要相互串接。
偵測有助於確認哪些系統需要處理。暫時性緩解措施可以降低部分攻擊路徑的風險。官方修補程式則用於處理底層漏洞。最後，透過驗證確認預期的補救措施是否成功部署。
Vicarius 的 vSociety 社群提供腳本與技術補救資源，供團隊評估並納入相關流程。
針對 PHP2Shell，可以先參考以下兩項資源：
CVE-2026-109618：緩解措施
CVE-2026-109619：漏洞偵測
部署前應先審查並測試這些腳本，並搭配官方供應商指引解讀執行結果。
常見問題
什麼是 PHP2Shell？
PHP2Shell 是 CVE-2026-109618 與 CVE-2026-109619 的統稱。這是兩項於 2026 年 10 月 21 日揭露的 PHP 重大記憶體安全漏洞，皆可能導致未經身分驗證的遠端程式碼執行。
PHP2Shell 漏洞的嚴重程度為何？
兩項 CVE 的 CVSS v4.0 分數均為 9.2，屬於重大風險。實際可被利用的風險會因 PHP 執行環境版本、組態及部署方式而有所差異。
PHP2Shell 可以在未經身分驗證的情況下遭利用嗎？
可以。PHP 資安團隊已確認這兩項漏洞存在未經身分驗證即可遠端執行程式碼的風險，並已證實在 mod_php 部署環境中，攻擊可於應用程式程式碼執行前觸發。但這不代表所有 PHP 組態都具有相同的攻擊路徑。
哪些 PHP 版本已修補 CVE-2026-109618 與 CVE-2026-109619？
已修補的上游版本為 PHP 8.5.12、8.4.27、8.3.36 及 8.2.35。使用由供應商維護之發行版的組織，應確認安全修補程式是否已回溯移植。
不安裝修補程式，能否完整緩解 PHP2Shell？
不能。PHP 官方明確提醒，暫時性緩解措施只能處理特定攻擊路徑。安裝已修補版本，或經確認的供應商安全更新，才是安全的正式補救方式。
資安團隊如何偵測可能存在的暴露風險？
團隊應盤點 PHP 執行環境、比對已安裝版本與供應商安全公告、評估相關組態，並使用適當的偵測資源。Vicarius 在 vSociety 上提供針對 CVE-2026-109619 的偵測腳本。
使用 WordPress 或其他 PHP 應用程式的網站會受到影響嗎？
如果 PHP 應用程式使用存在漏洞的 PHP 執行環境，就需要進行風險檢查。特定部署是否可遭利用，取決於執行環境及組態設定。只更新內容管理系統（CMS）或應用程式本身，不一定會同步更新 PHP。
最後提醒
CVE-2026-109618 與 CVE-2026-109619 再次提醒我們，重大應用程式暴露風險不一定源自應用程式程式碼，也可能存在於程式語言本身的執行環境。
對資安團隊而言，當務之急非常明確：找出存在漏洞的 PHP 部署環境、安裝官方安全更新、只在必要時使用暫時性防護措施，並確認正式環境實際執行的 PHP 已完成更新。
前往 vSociety 探索 Vicarius 的 PHP2Shell 腳本資源，協助漏洞調查與補救規劃；或洽詢 Vicarius 產品展示，進一步了解如何在企業環境中落實漏洞補救作業。
