PHP2Shell 爆發全球資安危機：兩項重大 RCE 漏洞的成因、攻擊原理與防禦策略

發布日期：2026 年 10 月 22 日
漏洞編號：CVE-2026-109618、CVE-2026-109619
嚴重程度：Critical（CVSS v4.0 9.2）

一、事件背景：PHP 核心漏洞引發全球資安警戒

2026 年 10 月 21 日，PHP 開發團隊緊急發布安全性更新，修補兩項存在於 PHP Runtime 核心的重大漏洞，分別為 CVE-2026-109618 與 CVE-2026-109619。這兩項漏洞統稱為 PHP2Shell，在特定條件下可讓未經身分驗證的攻擊者遠端執行任意程式碼（Remote Code Execution, RCE）。

與常見的網站應用程式漏洞不同，這次問題並非源自 WordPress 外掛、網站程式碼或 SQL Injection，而是直接存在於 PHP 執行環境底層的記憶體管理與錯誤處理機制。

這使得漏洞影響範圍不再侷限於特定網站功能，而是可能波及使用 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 與 LiteSpeed 等執行架構的網站及服務。

PHP 在全球網站生態系統中具有廣泛的使用基礎，包含內容管理系統、電子商務平台、企業入口網站、政府服務及各類 Web API。因此，核心層級的遠端程式碼執行漏洞，可能形成跨產業的系統性資安風險。

事件公開後，各國資安單位陸續發布警報，敦促企業立即確認 PHP 版本並安裝修補程式。

根據 Reuters 於 10 月 22 日的報導，Cloudflare 觀察到漏洞利用嘗試在公開後快速上升，達到數百萬次量級。日本部分金融機構、航空公司、鐵路服務，以及歐洲政府與企業網站，也因應風險暫停部分線上服務。

必須強調的是，漏洞利用嘗試不等於成功入侵，而預防性關閉網站也不代表相關單位已遭到攻陷。然而，短時間內大量攻擊流量的出現，已顯示漏洞資訊公開後，攻擊者迅速投入測試與掃描。

二、漏洞為什麼會發生？從記憶體管理看根本原因

此次事件涉及兩個相互關聯、但觸發機制不同的漏洞。

2.1 CVE-2026-109618：記憶體不足處理造成的記憶體毀損

第一項漏洞與 PHP 處理記憶體不足（Out-of-Memory, OOM）的方式有關。

PHP 透過 memory_limit 控制腳本可使用的記憶體。當程式執行時達到限制，PHP 需要中斷目前的工作，並執行錯誤處理及資源清理。

正常情況下，即使程式因記憶體不足而中止，執行環境仍應確保內部資料結構與資源狀態保持一致。

然而，漏洞的核心問題在於：當 OOM 發生於某些內部資料結構尚未完成初始化的階段，PHP 可能在清理過程中錯誤地將不完整的資料視為有效內容。

其概念流程如下：

1. PHP 開始處理外部 HTTP 請求。
2. 執行環境配置記憶體並初始化內部資料。
3. 特定操作造成 PHP 記憶體配置失敗。
4. PHP 透過錯誤處理機制中斷原本的執行流程。
5. 部分內部資料結構未完成正確初始化。
6. 後續清理程序仍使用這些無效資料。
7. 可能引發記憶體毀損，進一步導致程式崩潰或遠端程式碼執行。

PHP 使用的非區域跳躍機制 longjmp()，可能讓程式在發生 OOM 時跳過原本預期執行的初始化或清理步驟。

當記憶體配置、例外狀況處理與資源釋放之間缺乏一致的狀態保證，原本應該只是可控的錯誤情境，就可能演變為記憶體安全問題。

值得注意的是，PHP Foundation 已確認，在 Apache mod_php 的預設設定下，存在不需經過應用程式邏輯即可觸發的攻擊路徑。PHP-FPM 環境也已證實存在透過應用程式路徑達成遠端程式碼執行的情況。

這代表單純依靠網站的登入驗證、輸入檢查或框架安全機制，未必能阻擋這類攻擊。

2.2 CVE-2026-109619：全域狀態殘留造成 Use-After-Free

第二項漏洞則與 PHP Worker 處理多個請求時的狀態管理有關。

為了提升效能，PHP 執行環境可能重複使用相同的 Worker Process 處理不同 HTTP 請求。

雖然請求之間會共享部分執行環境，但每個請求所使用的暫存資料，仍應在生命週期結束時正確釋放或重設。

CVE-2026-109619 的問題在於，某些 PHP 全域狀態可能暫時指向由個別請求管理的記憶體。

當特定錯誤發生時，這些全域狀態可能未被正確清除，使得請求結束、記憶體釋放後，仍保留指向原有位置的參照。

後續請求如果在狀態重新初始化之前使用這些參照，就可能發生 Use-After-Free（UAF）。

攻擊流程可概念化為：

1. 第一個 HTTP 請求進入 PHP Worker。
2. 請求處理過程觸發特定錯誤。
3. 部分全域狀態仍指向請求專屬記憶體。
4. 第一個請求結束，相關記憶體遭到釋放。
5. 相同 Worker 處理後續請求。
6. PHP 在狀態完全重新初始化前存取舊參照。
7. 造成 Use-After-Free，可能進一步導致記憶體洩漏、程式崩潰或任意程式碼執行。

攻擊者一旦能夠影響相關記憶體內容及執行流程，就有機會將原本的記憶體安全問題擴展為遠端程式碼執行。

PHP Foundation 表示，研究人員已確認此漏洞可造成 Worker 崩潰，並曾在使用 Apache mod_php 的真實應用環境中展示遠端程式碼執行。

兩項漏洞雖然具有不同的觸發條件，但共同反映出 PHP 核心在異常執行路徑中，對內部資料狀態與生命週期的管理存在安全缺口。

三、漏洞為什麼直到現在才修補？

這次事件另一項值得關注的議題，是漏洞的發現與修補歷程。

根據 PHP Foundation 於 10 月 21 日公開的說明，與 CVE-2026-109618 有關的記憶體管理問題，其實早在 2024 年就已發現初步跡象。

當時 PHP 在外部安全稽核過程中，開發人員注意到 OOM 處理機制可能存在異常，但尚未找到具體且可靠的遠端攻擊路徑。

修補困難主要來自三個層面。

首先，PHP 核心涉及大量相互依賴的元件。 修改底層記憶體管理機制可能影響第三方擴充模組，甚至導致既有應用程式不相容。

其次，安全修補本身可能引進新問題。 某些候選方案雖然能避免特定記憶體錯誤，卻可能提高阻斷服務風險，或需要對既有程式架構進行大幅調整。

最後，核心維護資源與決策流程不足。 PHP Foundation 坦承，當時安全團隊缺乏足夠的專職人力，且在多種修補方案之間難以形成決策，使問題長期未能解決。

2026 年 8 月，情勢出現重大轉變。

安全研究公司 Calif 的研究人員於 8 月 11 日提出可實際達成遠端程式碼執行的攻擊方法。OpenAI 也獨立回報相同根本原因，Wiz 隨後提出其他攻擊路徑，使 PHP 團隊重新評估漏洞的實際嚴重性。

隨著攻擊可行性獲得證實，PHP Foundation 將修補工作提升為最高優先事項，並與不同安全研究團隊協作。

此次事件顯示，漏洞是否具有可實際利用的攻擊路徑，會直接影響風險評估與修補優先順序；但尚未發現攻擊方法，不代表底層缺陷本身不具危險性。

四、從協調揭露到資訊外洩：攻擊風險如何快速擴大？

原先 PHP 開發團隊預定於 2026 年 10 月 22 日公開漏洞與修補程式。

然而，10 月 20 日，兩項 CVE 編號提前出現在網路論壇及社群媒體，部分流傳內容還錯誤宣稱漏洞具有 CVSS 10.0 的最高評分。

實際上，PHP 官方確認的評分為 CVSS v4.0 9.2。

儘管最初流出的資訊不包含完整技術細節，但 PHP 團隊仍決定提前發布預告，並將正式修補日期提前至 10 月 21 日。

隨後，一家參與漏洞研究的安全公司意外公開展示概念驗證（Proof of Concept, PoC）的影片，進一步提高外界對漏洞利用方式的理解。

此外，PHP Foundation 指出，部分預先取得修補程式的軟體供應商在協調揭露時間之前發布已修補的映像檔，使外界可能在正式公告前透過修補差異分析推測漏洞所在位置。

這些事件反映出重大漏洞揭露中的典型難題：

• 過早公開可能讓攻擊者在修補程式普及之前取得利用線索。
• 過晚公開可能使已知的安全風險繼續存在。
• 不同平台、Linux 發行版與託管服務需要時間完成套件封裝和相容性測試。
• 若協調揭露流程中有任一參與方提前發布資訊，可能打亂整體防禦部署時程。

因此，重大漏洞管理不只是技術上的修補問題，也涉及安全研究人員、開源社群、軟體供應商與企業使用者之間的跨組織協調。

五、實際影響範圍與攻擊風險

本次漏洞影響 PHP 核心，而非單一內容管理系統或特定框架。

因此，即使 WordPress、Drupal 或 Joomla 本身已更新至最新版本，只要底層 PHP Runtime 仍存在漏洞，網站依然可能面臨相關風險。

PHP 官方目前提供下列修補版本：

PHP 分支	受影響版本	已修補版本
PHP 8.5	低於 8.5.12	8.5.12
PHP 8.4	低於 8.4.27	8.4.27
PHP 8.3	低於 8.3.36	8.3.36
PHP 8.2	低於 8.2.35	8.2.35
PHP 8.1 及更舊版本	官方已停止支援	升級或採用供應商安全回補

PHP 官方亦提供 PHP 7.4、8.0 與 8.1 的有限原始碼回補修補，主要供自行建置或無法取得長期支援供應商更新的使用者使用，但這並不代表這些舊版分支重新獲得完整安全維護。

其中，Apache mod_php 被官方列為風險最高的部署方式，因為已有研究證明，攻擊者可能在應用程式碼執行前觸發漏洞。

若攻擊成功，可能造成的影響包括：

• 遠端程式碼執行： 攻擊者在 PHP 執行程序的權限範圍內執行惡意指令。
• 敏感資訊洩漏： 記憶體中的部分資料可能暴露，例如與應用程式執行有關的機密資訊。
• 網站或服務遭到控制： 攻擊者可能植入 Web Shell、修改網頁內容或建立持續性存取方式。
• 橫向移動風險： 若遭入侵的網站可連線至內部資料庫或其他服務，攻擊者可能進一步利用其既有權限。
• 阻斷服務： 記憶體錯誤可能造成 PHP Worker 崩潰，使網站服務受到影響。

上述影響代表可能的攻擊後果，並非所有受影響的 PHP 系統都必然能在相同條件下被成功利用。

六、如何確認系統是否受到影響？

企業應首先建立 PHP 資產清單，確認所有使用 PHP 的網站、容器、虛擬機器及第三方設備。

對於可登入的 Linux 主機，可以先使用下列指令：

php -v

確認 CLI 使用的 PHP 版本，但需要注意，CLI 版本未必與網站實際使用的 PHP-FPM 或 Apache 模組版本相同。

也可以進一步查詢：

php-fpm -v

依照發行版或安裝方式，指令名稱可能包含版本編號，例如 php-fpm8.4。

若使用 Debian 或 Ubuntu，可查詢已安裝的 PHP 套件：

dpkg -l | grep -E 'php|libapache2-mod-php'

使用 RHEL 類型的系統，可查詢：

rpm -qa | grep -i php

如果 PHP 透過 Docker 容器執行，也必須檢查容器映像檔與實際運行版本，而不能只依靠宿主機的 PHP 版本。

此外，某些 Linux 發行版可能透過 Backport 方式，將安全修補套用至較舊的版本編號。因此，不能單純依據版本字串判斷是否已修補，仍應確認套件供應商的安全公告及修補狀態。

七、修補與暫時性防禦策略

7.1 優先升級 PHP Runtime

最直接且完整的修補方式，是升級至 PHP 官方已修補版本，或使用作業系統供應商提供的對應安全更新。

企業應優先處理對外提供服務的網站與 API，並確認以下事項：

1. 更新 PHP 執行環境，而不只是網站框架或外掛。
2. 確認所有 PHP-FPM Pool、Apache 模組及容器均已更新。
3. 重新啟動相關服務及 Worker Process。
4. 驗證實際處理 HTTP 請求的 PHP 執行環境已套用修補。
5. 進行必要的相容性測試，並持續觀察系統運作。

若系統仍使用 PHP 8.1 或更舊版本，應評估升級至仍受支援的分支，或確認所使用的長期支援供應商是否已提供安全回補。

7.2 無法立即修補時的風險降低措施

PHP 官方明確指出，目前不存在可以完全替代安全更新的緩解方式。

對 CVE-2026-109618，官方提出的暫時措施包含：

• 將 PHP 的 memory_limit 設為 -1，避免特定 PHP 記憶體限制觸發路徑，但仍需考慮實體記憶體耗盡風險。
• 限制 HTTP POST 請求大小與檔案上傳規模。
• 在 Web Server 或 Reverse Proxy 層限制輸入欄位數、Multipart 區塊數及其他請求複雜度。
• 透過適當的容器或 cgroup 資源限制，降低單一 Worker 對整體系統可用性的影響。

不過，取消 PHP 記憶體限制本身可能使惡意請求消耗更多系統資源，因此必須搭配作業系統層級的資源隔離與監控。

針對 CVE-2026-109619，官方建議可在適用情況下關閉 Session Upload Progress：

session.upload_progress.enabled = 0

若使用 PHP 8.5，也可依照官方指引暫時關閉：

fatal_error_backtraces = 0

這些設定必須在請求解析前生效，並重新啟動相關 Worker。

然而，這些措施只能降低已確認攻擊路徑的風險，不能保證阻止其他變形利用方式。

7.3 加強偵測與事件調查

對於尚未完成更新，或在漏洞公開期間持續對外提供服務的系統，建議進行威脅獵捕與日誌分析。

可優先關注以下異常行為：

• 短時間內大量異常 HTTP POST 請求，特別是 Multipart 請求及異常大小的輸入內容。
• PHP-FPM 或 Apache Worker 發生不尋常的崩潰、重新啟動或記憶體錯誤。
• Web Server 程序產生非預期的子程序或命令列執行行為。
• 網站目錄出現未知 PHP 檔案、可疑腳本或非預期的檔案修改。
• PHP 服務帳號產生異常對外網路連線。
• 應用程式出現不尋常的 Fatal Error、記憶體不足錯誤或 Session 處理異常。

例如，在具備適當稽核紀錄的環境中，若觀察到 PHP Worker 異常啟動 Shell 或系統管理工具，便值得進一步調查。

但這些行為只能作為潛在入侵跡象，並不構成 PHP2Shell 的專屬偵測特徵。實務上仍需結合請求紀錄、程序行為、系統異常與威脅情資進行交叉分析。

WAF 可協助限制異常輸入與部分已知攻擊模式，但由於漏洞存在於 PHP 核心的記憶體及錯誤處理流程，單純依靠字串特徵或封鎖特定 Payload，無法保證完整防護。

八、事件帶來的啟示：AI 加速漏洞發現，也放大防禦壓力

這次事件有三個值得關注的資安研究議題。

第一，AI 正在改變漏洞挖掘與驗證的速度。

PHP Foundation 公開指出，多個研究團隊及 AI 輔助工具參與了漏洞發現、報告驗證與攻擊路徑確認。AI 不一定獨立完成整個漏洞發現過程，但已開始協助研究人員分析大型程式碼庫、尋找異常處理路徑，以及驗證不同報告是否具有共同根本原因。

這些技術使過去難以大量人工檢查的程式狀態與執行路徑，更容易被系統性分析。

第二，漏洞的危險性不一定與存在時間成正比。

部分程式缺陷可能已存在多年，卻因缺乏可靠利用方式而未被視為最高優先事項。隨著研究工具與攻擊技術進步，原本被認為難以利用的問題，可能重新被評估為重大安全威脅。

這代表資安團隊不能只根據是否已有公開 Exploit 判斷漏洞是否值得修補。

第三，開源軟體安全不只是程式碼品質，也是治理與資源配置問題。

PHP Foundation 坦承，有限的人力資源與既有決策流程延誤了修補進度。對於被大量企業與政府依賴的基礎技術而言，如果核心維護工作長期缺乏充足資源，便可能使局部技術問題發展成大規模安全事件。

未來除了導入 AI 安全測試、Fuzzing 與 Sanitizer，開源專案也需要更成熟的漏洞分級、協調揭露、修補測試與資源投入機制。

九、結論

PHP2Shell 再次凸顯，重大資安漏洞不一定發生於應用程式的業務邏輯，也可能隱藏在開發人員平時不會直接接觸的執行環境底層。

CVE-2026-109618 與 CVE-2026-109619 分別涉及記憶體不足處理與全域狀態殘留問題，在特定條件下可造成未經驗證的遠端程式碼執行。

此次事件從早期問題發現、修補決策延宕、攻擊路徑驗證，到資訊提前揭露與緊急修補，完整反映出現代軟體供應鏈在面對底層安全漏洞時所承受的技術與治理壓力。

對企業而言，目前最重要的行動仍然是盤點所有 PHP 執行環境、優先修補對外系統、確認更新確實生效，並針對漏洞公開期間的可疑活動進行調查。

對資安研究社群而言，這起事件則提供了一個重要案例：當 AI 輔助漏洞研究逐漸成熟，漏洞發現速度與利用驗證能力將持續提升，而防禦方的修補流程、協調能力及軟體維護資源，也必須同步進化。

---

參考資料

1. PHP 官方安全公告（2026/10/21）
   https://www.php.net/archive/2026.php
2. PHP Foundation — Today’s PHP Security Release, and How We’re Strengthening PHP Security
   https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
3. CVE-2026-109618 — PHP GitHub Security Advisory
   https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
4. CVE-2026-109619 — PHP GitHub Security Advisory
   https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
5. Canadian Centre for Cyber Security — Critical Vulnerabilities Impacting PHP
   https://www.cyber.gc.ca/en/alerts-advisories/al26-026-critical-vulnerabilities-impacting-php-cve-2026-109618-cve-2026-109619
6. Reuters（2026/10/22）— Millions of Hacking Attempts as Companies, Governments Rush to Patch PHP Flaws
   https://www.reuters.com/world/asia-pacific/cloudflare-sees-millions-exploit-attempts-after-php-disclosure-2026-10-22/
7. WordPress — Critical PHP Security Release
   https://wordpress.org/news/2026/10/critical-php-security-release/