PHP2Shell：利用嘗試與修補趨勢

上週，我們釋出了一份報告，描述了 PHP 的兩個主要漏洞（CVE-2026-109618, CVE-2026-109619）。此後，與安全產業的許多團隊一起，Wiz 研究團隊一直在監控野外相關活動並審查公開可得的利用程式碼。迄今為止，我們在通訊資料中觀察到有限數量的利用嘗試，且未發現任何公開可用的概念驗證（PoC）能完整、普遍地完成對任意目標的端到端利用。一些合作夥伴雖然私下向我們披露了能對多種目標起效的利用程式，我們仍在內部進行實驗。展示我們成功利用的影片可於php2shell.com觀看。

本篇文章總結至今我們在實際環境及自家蜜罐資料中觀察到的補救措施與利用嘗試，並分享我們持續調查這些活動所得到的發現。

我們將持續監測進展，並在有新證據出現時更新此文章。

觀察到的曝露趨勢

在 2026 年 10 月 21 日 PHP2Shell 公開披露後，Wiz 的通訊資料顯示過去數日內每日遭受 PHP2Shell 漏洞影響的獨立網際網路曝露機器數量約下降 67%。此外，在易受攻擊的網際網路曝露機器中，執行 PHP 7.3 或更舊版本的比例從 8.3% 降至 5.7%，為期五天。此數值衡量的是使用未獲官方回溯版本的舊版 PHP 的觀測族群比例。

在此期間，受顯著影響的組織數（此處定義為至少有一臺曝露且易受攻擊的例項）下降約 47.9%（見下圖）。作為參考，我們的資料顯示 PHP 本身在我們資料集中的 65% 組織中被使用。

綜合來看，這些觀察結果與組織透過修補、升級、淘汰受影響機器及限制網際網路存取等多重措施共同降低曝露相符（請注意，這些資料顯示整體趨勢，但未能確定每種補救策略的相對貢獻；掃描覆蓋範圍與觀測族群大小亦可能隨時間影響整體報告數字）。

Wiz 研究團隊觀察到的利用嘗試

至今，我們在此情境下觀察到以下型別的活動：

1. 使用 PHP2Shell 利用機制的嘗試，其技術與公開 PoC 相符.

2. 與漏洞無關的 PHP2Shell 品牌工具，其實則依賴會話毒化與應用程式中另一個本地檔案包含（LFI）漏洞。

使用 PHP2Shell 利用機制的嘗試

我們觀察到兩個針對 PHP 為基礎軟體的開源利用工具包變體。兩者皆未完成我們所捕捉的利用鏈。舊版變體遇到請求大小限制或無法產生預期的記憶體耗盡狀況；新版變體則持續耗盡 PHP 的記憶體，但未能取得繼續執行所需的記憶體位址。

變體 1：傳統鏈

第一個對我們 PHP-CGI 蜜罐的請求來自 3.37.227[.]134。它匹配了套件的舊鏈，位於 archive/legacy-8m/exploit.py 以及其相應的階段指令碼。第一個完整的利用階段使用了一個 multipart 主體，包含 1,005 個部分，其中一個名為 big 的欄位填充了約 12 MB 的填充資料：

根據套件的說明，該階段試圖在會話重置時耗盡記憶體，從而使會話狀態在後續請求中可用。

在我們的蜜罐上，它在到達該程式碼之前就失敗了。宣告的請求大小超過了設定的 8 MB post_max_size 限制，因此 PHP 跳過了 multipart 主體的處理並記錄了：

作者已將此鏈移至套件的 archive 目錄。

後續針對 Roundcube 的嘗試

在後續嘗試中，103.151.172[.]95 發送了更長的舊鏈序列。它包含了停滯的連線，旨在佔用其他 Apache 工作者。

當僅有一個工作者可用時，利用程式嘗試透過傳送包含 1,001 個 3,000 位元組欄位的請求來進行堆疊塑形。這些請求未觸發所需的記憶體耗盡流程。因此，沒有證據表明此嘗試達到預期的記憶體耗盡條件。

變體 2：目前的鏈

我們捕獲的大多數 IP 位址使用了由 pure/mk_a1.py 和 pure/mk_leak_b.py 構建的更新鏈。我們在多次嘗試中觀察到此變體。

此變體進一步發展：其第一階段始終導致 PHP 耗盡記憶體。隨後的階段試圖洩漏程序記憶體，但我們捕獲的每一次執行都失敗。

伺服器記錄了一個致命錯誤，表明 PHP 達到其限制，例如：

將請求保持在同一工作者上

該鏈依賴連續的利用請求到達同一個 Apache 子程序。為了提高此情況發生的機會，套件試圖用不完整的請求佔用其他工作者。每個連線宣告一個大型主體，傳送一個位元組並停滯：

一個位址 178.249.214[.]6 在傳送利用階段之前，開啟了 399 個此類連線以及 400 個 GET 請求。該位址為 VPN 出口節點，限制了我們對來源的推斷。

階段 A1：觸發記憶體耗盡

A1 是一個分塊的 multipart 請求，包含一個空位元組的 session ID、860 個空檔案部件（具有長且深層巢狀的陣列名稱）以及幾組填充欄位：

該請求旨在於會話處理期間耗盡記憶體，並可能使 session ID 指向已釋放的記憶體。

我們捕獲的每一次 A1 請求都返回 HTTP 500，伴隨著符合以下的 PHP 錯誤：

這證實 A1 在我們的蜜罐上達到了預期的記憶體耗盡條件。但僅此並未確認下一階段所需的過期會話狀態是否被保留。

階段 B1：嘗試記憶體洩漏

B1 大約在一秒後跟進。它發送了另一個分塊的 multipart 請求，包含 PHPSESSID=a、PHP_SESSION_UPLOAD_PROGRESS=k0 和兩個大型填充欄位。

如果此請求在 PHP 重置過期會話狀態之前到達同一工作者，PHP 可以將回收的堆內容寫入 PHPSESSID 響應 cookie。套件隨後從該 cookie 提取堆和 libphp 地址，以準備最終利用階段。

我們未觀察到此類洩漏。在除一次之外的所有執行中，連線在未回應的情況下關閉。剩餘一次執行返回了一個正常的 32 字元 session cookie。沒有任何來源傳送最終利用階段。

為何洩漏可能失敗

失敗的記憶體洩漏凸顯了更廣泛的挑戰：構建一個能在不同 PHP 版本與部署設定下可靠運作的通用利用程式十分困難。此套件的 B1 佈局是針對官方 php:8.4.26-apache 映像檔、128 MB 記憶體限制所計算。像我們的 Roundcube 蜜罐等其他例項則使用相同 PHP 版本的不同建構，並搭載額外擴充套件與 64 MB 記憶體限制。這些差異可能影響堆疊佈局與記憶體重複使用，進而使洩漏無法如預期運作。

可靠的工作者固定（worker pinning）又帶來另一個挑戰。連續的利用請求必須到達同一個 Apache 子程序，且必須維持所需的會話狀態。請求逾時、網路延遲與工作者可用性都可能中斷此流程。在我們自己的測試中，請求逾時與網路延遲的結合足以阻止整個鏈條在網際網路連線上完成。

迄今為止，我們尚未發現任何公開、通用的解決方案，無論是針對工作者固定還是跨不同部署的資訊洩漏。僅僅複製公開的 PoC 並大規模執行，並不能解決將特定配置利用程式轉化為可靠運營工具所需的工作。我們預期這些障礙隨時間會降低：部分威脅行為者具備足夠專業知識，可調整鏈條並構建更穩健的工具。

其他嘗試

我們還看到來自 15.204.59[.]70 和 162.35.99[.]94 的失敗利用嘗試，但這些掃描器確實成功利用了 Adel Karimi 的蜜罐，這可能是 CISA 決定將 PHP2Shell 列入其 KEV 清單 的主要原因之一。

與漏洞無關的 PHP2Shell 品牌工具

我們也觀察到標示為 PHP2Shell 利用程式的工具，但實際上並未嘗試利用任何漏洞。最早的此類流量來自 85.11.187[.]35，與 WoYinDao/CVE-2026-109618-CVSS-9.2-Critical 的 Go 版「Chain A」相符。

該工具使用長期存在的會話汙染技術，試圖透過上傳進度功能將 PHP 程式碼寫入會話檔。以下請求已被簡化：

接著它嘗試透過包含該會話檔執行程式碼：

關鍵的是，lfi_sink.php 是 PoC 實驗室環境提供的易受攻擊端點。該工具假設目標上存在此端點；若缺少此端點或等效的本地檔案包含（LFI）漏洞，鏈條便無法執行程式碼。

一個填充變體觸發了我們的記憶體耗盡偵測，但我們未觀察到成功的程式碼執行。儘管使用 PHP2Shell 品牌，該活動仍依賴於無關技術與易受攻擊的應用端點。

結論

我們尚未在自身的遙測資料中觀察到成功的端到端 PHP2Shell 利用。然而，Adel Karimi 的公開報告與支援資料提供了迄今為止最堅實的公開證據，將利用流量、記憶體洩漏與隨後在其蜜罐上執行的程式碼相關聯。值得注意的是，這些目標使用了有利的單工作者 Apache mod_php 配置，因此此結果並未證明在其他部署中的可靠性。

我們的觀察顯示，僅觸發記憶體耗盡並不足以完成整個利用鏈。PHP 版本、記憶體上限與工作者行為的差異可能阻止後續階段運作。機會主義攻擊者的挑戰是將目前可用的公開 PoC 轉變為同樣可靠的運營工具，或自行開發。對我們而言，PHP2Shell 在短期與長期均仍是風險，故仍須套用 PHP 安全更新或透過其他方式進行修復。

IOCs