PHP 兩大 RCE 漏洞（CVE-2026-109618/109619）已被多家雲端服務商觀測到攻擊，緊急升級提醒

首次釋出於 2026 年 10 月 22 日，最後更新於 2026 年 10 月 23 日 16:45 CEST。此公開作業指引提供給客戶並為更廣泛社群釋出。TLP:AMBER 資訊透過常規管道披露。

TL;DR

何者：兩個關鍵 PHP 漏洞已被披露，CVE-2026-109618（透過 OOM 破壞實現 RCE）和 CVE-2026-109619（透過舊全域狀態實現 RCE），統稱 PHP2Shell。兩者均評為 CVSS v4.0 9.2（嚴重）。第三個風險較低的 CVE（CVE-2026-115560）於 10 月 23 日披露，將於常規發布週期釋出。
受影響者：任何處理網頁請求的 PHP 安裝，包括 PHP-FPM、Apache 的 mod_php、php-cgi、FrankenPHP 及 LiteSpeed。特別注意 Apache 的 mod_php，已證實存在未經身份驗證的利用。
利用狀態：Amazon、Cloudflare、WatchTowr 與 NVISO 已觀測到活躍的利用嘗試。尚未確認成功的佔領或可靠的公開利用，但 PoC 申報正在流傳。
應該怎麼做：立即將 PHP 更新至 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35，優先針對對外網路系統。若更新延遲，請套用 PHP 的漏洞特定緩解措施（詳細說明如下）。確認網頁伺服器程序實際使用已修補的執行環境。

發生了什麼事？

2026 年 10 月 20 日，兩個關鍵 PHP 漏洞的資訊在預定的協調披露之前已公開。這些漏洞分別為 CVE-2026-109618 與 CVE-2026-109619，每個漏洞均獲得 CVSS v4.0 分數 9.2（嚴重）。

為此，PHP 安全團隊宣佈將於 2026 年 10 月 21 日 14:00 UTC（16:00 CEST）發布緊急安全補丁，若技術細節公開或偵測到活躍利用，可能提前發布。

兩個漏洞均可能允許未經身份驗證的遠端程式碼執行（RCE）。成功利用可使遠端攻擊者在易受攻擊的伺服器上執行惡意程式，可能破壞其上託管的應用程式與資料。

2026 年 10 月 21 日 13:30 UTC（15:30 CEST），PHP 安全團隊釋出緊急補丁以解決兩個漏洞。

以下為最低已修復的上游 PHP 版本：

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 及更舊版本	無標準上游釋出；需供應商回溯或遷移。

2026 年 10 月 23 日，PHP 安全團隊釋出另一漏洞的資訊性諮詢：CVE-2026-115560。此漏洞需要特定的設定與應用程式程式碼組合。由於 PHP 安全團隊評估此漏洞被利用的可能性不高，補丁將於常規釋出週期釋出，而非像 CVE-2026-109618 與 CVE-2026-109619 那樣的緊急補丁。

為何組織應關注？

PHP 是網頁開發中最廣泛使用的伺服器端程式語言之一。它是許多網站、內容管理系統（CMS）、電子商務平臺、客戶門戶與商業應用的基礎。

像 WordPress、Drupal、Joomla 和 Magento 等熱門平臺都依賴 PHP 來執行應用程式邏輯。與影響特定外掛或單一網頁應用的漏洞不同，PHP 本身的漏洞可能會影響依賴相同底層執行環境的多個應用程式。這使得潛在的攻擊面特別寬廣。

組織可能在不知情的情況下執行 PHP。PHP 執行環境可能被嵌入於舊版應用、主機環境、內部管理門戶、容器以及第三方軟體中。

成功遠端程式碼執行的潛在後果包括：

未經授權的伺服器存取：攻擊者可能在受影響 PHP 程序的安全上下文中執行指令。
資料竊取：敏感資訊、應用程式機密、憑證或可被該程序存取的客戶資料可能會被洩露。
網站被攻陷：攻擊者可以修改應用程式內容、部署惡意指令碼或透過 Webshell 建立持續性。
運營中斷：被攻陷的應用程式可能被停用、被操縱，或被用來協助進一步攻擊。
橫向移動：被攻陷的伺服器可能成為對其他連線系統發動攻擊的初始踏腳石。

我們對這些漏洞瞭解什麼？

與 PHP2Shell 釋出相關的漏洞共有三個：

識別碼	嚴重性	影響
CVE-2026-109618	CVSS v4.0 9.2 – 重大	通過 OOM 損毀的遠端程式碼執行
CVE-2026-109619	CVSS v4.0 9.2 – 重大	通過過期全域狀態的遠端程式碼執行
CVE-2026-115560	未知	RCE

PHP 團隊提供了以下緩解步驟：

若您無法立即更新：雖然更新才是完整解決方案，以下措施可降低對特定攻擊路徑的暴露，但並不能使安裝安全。

RCE via OOM corruption (CVE-2026-109618):

設定 memory_limit=-1，最好以應用程式無法覆寫的方式，例如在 FPM 池或 Apache 設定中使用 php_admin_value，並檢查是否有任何池、目錄或應用程式設定重新設定有限制。這可消除可控的 PHP 記憶體限制失效，但底層的分配失效仍可能觸及脆弱
路徑。

設定一個 low post_max_size。對於不需要檔案上傳的應用程式，設定 post_max_size = 8M。若需要檔案上傳，設定 post_max_size = 32M。將 upload_max_filesize 保持在 post_max_size 以下。考慮在網頁伺服器或代理層強制執行限制，例如解碼後請求大小、輸入欄位數、multipart 部分數、標頭數、以及巢狀深度。這些限制亦必須涵蓋沒有可用 Content-Length 的請求。

使用容器或 cgroup 限制作為可用性邊界，最好使用只終止受影響工作者的策略。不要以 RLIMIT_AS 或 RLIMIT_DATA 取代，因為這些可能引發脆弱的分配失效。

RCE via stale global state (CVE-2026-109619):

設定 session.upload_progress.enabled=0 並重新啟動每個工作者。使用 php.ini，即在請求解析前套用的 FPM 池或伺服器設定。不要依賴 ini_set() 或 FPM .user.ini。這能阻止已確認的會話路徑，但無法阻止其他變體。

在 PHP 8.5 上，設定 fatal_error_backtraces=0 並重新啟動每個工作者。這僅能阻止已確認的致命回溯路徑。

移除每次請求時套用的無效或已棄用設定，這些設定會在初始化前產生診斷訊息。隱藏診斷訊息（error_reporting、display_errors 或 @）並不能解決問題。

修正可被攻擊者觸發的致命錯誤與執行時間過長，包括回呼、上傳或匯入處理以及清理時的失敗。

RCE (CVE-2026-115560)

設定 session.upload_progress.enabled=0 並重新啟動每個工作程序。

一般建議，PHP 團隊建議將 PHP 例項更新至 PHP 8.5.12、8.4.27、
8.3.36 或 8.2.35。

瞭解風險

遠端程式碼執行漏洞允許攻擊者在特定條件下，使易受攻擊的應用程式或軟體元件執行攻擊者控制的程式碼。成功的遠端程式碼執行可能導致破壞、資料庫外洩、部署網頁殼或惡意軟體，以及完全佔領所託管的應用程式。

PHP2Shell 是否已在實際環境中被利用？

截至 2026 年 10 月 23 日，仍有活躍的 PHP2Shell 利用嘗試，但尚未有成功佔領的證據。

2026 年 10 月 21 日，Amazon 安全團隊報告在其 MadPot 蜜罐基礎設施中偵測到 PHP2Shell 利用嘗試，並明確表示「PHP2Shell 現正被廣泛利用於實際環境中」。

Amazon 報告於：

2026 年 10 月 17 日：首次確認利用嘗試，距公開披露還有四天。

2026 年 10 月 21 日，02:00–08:00 UTC：來自多個匿名來源的額外利用嘗試。

2026 年 10 月 21 日，補丁發布後：額外的 PoC 出現並幾乎立即被用於攻擊 AWS 感測器。

Cloudflare 確認已觀察到針對其客戶的惡意流量，但未提供客戶系統已被佔領的證據。

NVISO 確認網路範圍內嘗試利用該漏洞，迄今未成功，且部分符合 Sophos 的觀察。我們也觀察到一些會導致伺服器崩潰的嘗試。

WatchTowr 亦確認實際環境中兩個漏洞的利用嘗試。

VulnCheck 公司聲稱擁有 CVE-2026-109618 的可執行利用程式，但我們尚未能確認其真實性。

目前至少有 748 個公開的 GitHub 倉庫與 PHP2Shell 相關，其中一些擁有超過千顆星。儘管如此，尚未有公開可用的利用程式被確認能可靠地完成對漏洞的完整利用。

開發可靠的利用程式相當困難，因為它需要在同時利用漏洞以實現穩定程式碼執行的同時，繞過地址空間佈局隨機化（ASLR）。隨著時間推移，編寫並免費公開分享利用程式需要不斷投入時間與金錢，降低了此舉的誘因。

缺乏公開可用的利用程式並不代表不存在可用的利用程式。參與協調披露漏洞的研究人員已擁有此程式，且威脅行為者可能已自行開發，儘管迄今尚未報告成功佔領。

組織如何保護自己？

NVISO 建議採取風險為基礎的回應，先針對對外網路與業務關鍵的 PHP 部署。

識別可能受影響的系統

優先事項是瞭解 PHP 的部署位置。組織應盤點面向網路的網站、內部應用程式、託管環境、容器，以及依賴 PHP 的第三方產品。對於每個安裝，應辨識 PHP 版本、託管平臺、應用程式擁有者、業務重要性與外部可存取性。不要忽略遺留應用程式或與供應商管理軟體捆綁的 PHP 執行環境。

在補丁部署前降低曝露風險

若無法立即修復，組織應考慮限制高風險 PHP 應用程式的存取。依業務需求，可能包括：

透過 VPN、網路允許清單或已驗證的閘道限制存取。
暫時停用非必要的面向網路的 PHP 服務。
將網路伺服器與敏感內部環境隔離。
審查出站連線並限制不必要的網路存取。
在可用的情況下，應使用已驗證的供應商提供的保護或 Web 應用程式防火牆規則。
Web 應用程式防火牆並非取代補丁的替代方案，尤其在漏洞的技術特性尚未完全確定時。

CERT-EU 建議考慮在無法立即補丁的情況下隔離面向網路的應用程式。

準備緊急補丁部署

PHP 安全團隊於 2026 年 10 月 21 日 13:30 UTC 釋出緊急安全更新。組織應透過確定負責的系統擁有者、遵循標準更新程式、安排維護視窗並制定適當的回滾計畫，迅速部署。套用更新時：

確認受影響及已修復的 PHP 版本。
套用相關安全更新，優先處理對外可存取的系統。
若 PHP 未直接管理，請與託管服務供應商及軟體供應商協調。
更新後驗證應用程式功能。
確認生產環境的網路伺服器流程使用已修補的 PHP 執行環境。

請注意，更新內容管理系統或網頁應用程式並不一定會更新底層的 PHP 安裝。
使用已停止支援的 PHP 分支的組織，應評估遷移至受支援的版本或取得
供應商維護的安全回溯確認。

加強偵測與監控

安全作業中心應加強對 PHP 基礎設施的監控，尤其是來自網路伺服器流程的意外行為。有效的偵測機會包括：

可疑流程執行：監控 PHP 或網路伺服器流程，例如 php-fpm、php-cgi、apache2 或 httpd，啟動意外的指令解譯器，包括 sh、bash 或 PowerShell。
潛在的有效載荷檢索：調查網路伺服器流程意外執行下載工具，例如 curl 或 wget，尤其在其後執行指令碼時。
可疑網路活動：檢視 HTTP 存取日誌、反向代理遠端資料、以及 WAF 事件，尋找不尋常的請求模式、對 PHP 端點的意外請求或伺服器錯誤顯著增加。
事後利用的跡象：監控網頁可存取目錄中新建的 PHP 檔案、意外的外向連線、可疑的排程任務、已修改的服務或未授權的使用者帳號
變更。這些是與網頁伺服器被入侵相關的一般行為偵測機會。它們不應被解讀為已驗證的 PHP2Shell 特定偵測簽章。若發現可疑活動，組織應儲存相關證據並調查是否在套用補丁前已被入侵。

確認修復並持續監控

補丁後應進行驗證。安全團隊應確認受影響的系統已成功更新、必要的服務已重新啟動，且沒有任何易受攻擊的執行環境仍在運作。

應特別留意負載平衡環境、容器、測試環境，以及由第三方供應商維護的系統。

由於攻擊可能在修復之前發生，組織還應檢視相關歷史遙測資料並調查入侵跡象。

接下來會發生什麼？

隨著補丁已公開，攻擊者正積極進行反向工程以產生可靠的利用程式。已在實際環境中觀測到利用嘗試（見上文），且預計在未來數日內隨著公開 PoC 成熟，攻擊頻率將會加劇。組織應將補丁視為時間關鍵，並持續監控官方 PHP 安全公告與可信賴的安全建議以獲取進一步更新。

NVISO 建議

我們立即的建議是識別 PHP 部署、優先處理暴露資產、降低
攻擊面、準備緊急補丁，並加強安全監控。鑒於這些漏洞的嚴重程度與潛在影響範圍，組織不應等到確認廣泛利用後才採取預防措施。

NVISO 的威脅情報與 CSIRT 團隊將持續監控此發展中的情況。若您的組織需要協助評估曝露、回應潛在利用或
調查可疑活動，請聯絡 NVISO CSIRT。

參考資料