PHP2Shell 解析：AI 加快漏洞研究，誰來完成修補？（2026）

2026 年 10 月 21 日，Wiz Research 在官方部落格發布了〈PHP2Shell: AI uncovers critical RCE vulnerabilities affecting 70% of the Internet〉，公開 AI 協助研究 PHP 核心漏洞的過程。這起 PHP2Shell 事件值得注意的，是老問題如何變成可實際利用的風險，以及修補為何需要整個軟體生態系接力。

先讀清楚研究團隊真正展示了什麼，再對照 PHP 維護者的公告與事件回顧，最後回到一個實際問題：當找洞變快，誰有能力把洞補完？如果你管理網站，可以直接先看文末的修補核對表。

PHP2Shell 的核心：錯誤結束後，狀態沒有一起結束

PHP 是執行網站程式的底層環境。這次問題位於 PHP 引擎的記憶體與錯誤處理，不能單看 WordPress 外掛是否更新，就判定底層已經處理完成。Cloudflare 的防護說明也明確區分：應用程式或外掛更新，與 PHP runtime 本身的修補，是不同工作。

用共用工作桌來想像：上一位同事離開時，把一張已作廢的資料位置留在桌上；下一位同事看到這張紙，以為它仍然有效，就去讀取或操作已換用途的空間。另一種情況則是物品還沒擺好，清理程序已把它當成完成品處理。這兩種比喻分別對應殘留狀態與未完成初始化，並不表示每次記憶體不足都會被入侵。

PHP 的兩份正式公告把問題分成 CVE-2026-109618：OOM 處理造成狀態毀損，以及 CVE-2026-109619：跨請求殘留的全域狀態。前者涉及清理不完整資料，後者涉及使用已釋放記憶體；在可到達的執行路徑和相應條件下，結果可能超過程式崩潰，進一步成為遠端程式碼執行。

Wiz 報告整理了四類具體路徑：上傳進度的反序列化、程序記憶體洩漏、致命錯誤回溯，以及 OPcache 型別混淆。它們被歸到兩個 CVE，不能把「四個研究案例」誤讀成四個 CVE，也不應把其中一條路徑的條件套到全部部署。

AI 的貢獻在哪裡？研究展示與能力結論要分開

This changes the economics of both discovery and exploitation.

中文：這改變了漏洞發現與利用兩端的成本結構。

Wiz Research，2026 年 10 月 21 日

原文真正想說的是：模型接上測試與除錯工具後，可以協助反覆分析失敗，調整不同版本與記憶體配置下的研究方案。Wiz 表示這次使用了 Wiz Atlas、Gemini 4 Argon 與 GPT-5.6 Sol，並特別肯定 Argon 在尋找漏洞、利用研究、偵測與修補驗證上的貢獻。這是研究團隊對工作過程的歸因。

Wiz 也報告，在當時測試使用的 WordPress、Drupal、Joomla 容器部署上展示了無須身分驗證的遠端程式碼執行，並另外展示記憶體讀取。這些案例說明底層問題能穿過不同應用；它們不是對每個網站、每種設定的普查，也不是 AlphaLab 在正式網站上重現的結果。

我的判讀是，最有意義的能力是「降低一連串實驗的成本」。想法要經過執行、觀察、修正，才變成可信的研究成果。這與 Agent Harness 的工作迴圈相通：模型提供候選推論，工具帶回現實回饋，驗收決定哪一個說法站得住腳。

原文把單一研究者一週的成果，與過去頂尖團隊數月的工作相比；這段是作者對工作量的經驗判斷，與同題、同環境、保留失敗樣本的人機對照實驗有不同的證據強度。因此這個比較應保留作者歸屬，不能拿來計算普遍適用的加速倍率，更不能據此替三個模型排資安能力名次。

70% 的網際網路？先把分母與部署條件分清楚

Wiz 標題把影響範圍寫成網際網路的 70%。可核對的 W3Techs 統計頁在 2026 年 10 月 21 日顯示的數字是 69.3%，分母是伺服器端程式語言可被辨識的網站。它描述 PHP 的使用普及程度，並未測出其中多少站仍未修補、符合某條利用路徑，或已遭入侵。

因此，要分開問三件事：網站是否使用 PHP？實際執行的套件是否含修補？部署是否符合已知或潛在的利用條件？第一題的市占數據，不能直接代答後兩題。這不會讓事件變得輕微，卻能避免用一個很大的數字取代真正的資產盤點。

PHP 官方安全公告把所有服務網頁請求的 PHP 安裝列為需要處理的風險範圍，涵蓋 PHP-FPM、Apache mod_php 等方式，並指出 mod_php 風險最高：已有在應用程式碼執行前即可觸發的展示。PHP Foundation 另確認，PHP-FPM 也有透過應用層路徑達成遠端執行的案例。「不是 mod_php」不能當作不更新的理由；「都要更新」也不表示每個環境的攻擊條件完全相同。

這是 10 月的公開揭露，研究與困難決策早已開始

Wiz 把自己的首個發現記在 8 月 19 日，8 月 24 日向 PHP 團隊通報。PHP Foundation 的事件回顧則補上更早的脈絡：2024 年安全稽核後，核心開發者已有 OOM 問題的跡象；當時尚未找到具體利用路徑，修法又牽涉相容性、阻斷服務與擴充套件負擔，處理一再停滯。

Foundation 表示，Calif 與 OpenAI 在 2026 年 8 月 11 日回報同一根本原因，之後又有其他攻擊路徑與 Wiz 的通報。這讓「舊問題的影響被進一步證實」比「10 月突然從零發現一切」更符合公開紀錄。單看任一研究團隊自己的時間線，都看不完整個協作過程。

公開揭露也有協調成本。Foundation 記錄，10 月 20 日 CVE 編號提前流傳後，原訂 10 月 22 日的發布被提前到 10 月 21 日。對維護者而言，爭取時間不只是寫好程式：還要讓發行版、主機商與使用者在細節公開時，有真正可安裝的修補包。這是速度、可更新性與資訊外流之間的艱難安排。

AlphaLab 的判讀：找洞變快，修補能力更值得投資

一、AI 讓「難以利用」更需要被重新檢查

我同意原文的核心提醒：一個漏洞過去很難變成可靠攻擊，不代表這個難度會永久維持。如果反覆測試與改寫的成本下降，原先因成本太高而少有人追的路徑，就值得重新排序。對防守者，合理反應是優先盤點共用底層與高影響元件，並用可重現的證據更新修補順位。

二、更多報告，不會自動變成更多修補

a person makes every call and works on every patch.

中文：每個判斷與每個修補，仍都有人參與。

The PHP Foundation，2026 年 10 月 21 日；原句末段

Foundation 描述自 7 月 1 日以來發布 15 個 CVE，同時處理超過 100 份無效、重複或無法重現的報告。這不是 AI 全部無用的證明；它提醒我們，報告數、有效漏洞數與修補交付數，是三個不同分母。若入口成長，審查、去重與修補人力沒有跟上，等待處理的工作就可能增加。

因此團隊評估 AI 資安工具時，應要求同時交代有效報告比例、重現所需時間、修補與回歸測試負擔。這套思路可以接到 AI Evals 的驗收方法：成功條件先寫成能觀察的結果，再評估模型輸出是否真的減少總工作量。

三、修補要承擔相容性，模型排行代替不了維護判斷

找出一條會失敗的路徑，是研究成果；選出不破壞大量既有軟體的修法，則需要理解相依關係、檢查回歸並承擔發布責任。AI 可以協助其中的分析與測試，但本次事件本身不能證明這些工程判斷已被全面自動化。要放大防守效益，資源應同時流向工具與熟悉核心程式的維護者。

把驗收和環境一起設計，比只增加模型權限更有用；建立 Agent Harness能補上工具回饋、停止條件與交付檢查的基本觀念。若讓代理接觸程式與設定，也應先依 Agent 密鑰安全指南限制憑證與資料邊界。

四、我同意風險升高；我存疑的是把展示直接外推

我同意這是值得認真處理的 AI 輔助研究案例：PHP 維護者已確認嚴重問題並發布修補，證據超過單純聊天截圖。我存疑的，是把特定研究經驗放大成所有攻擊都很容易、七成網站都已失守，或某個模型已可獨立取代安全團隊。這幾個結論都需要額外證據。

Wiz 同時提供防護產品，原文也有產品導流；這是理解敘事動機的背景，不是反駁漏洞的證據。最公平的讀法，是把已確認的底層風險、作者報告的模型貢獻，以及我們對未來成本變化的推論分開。原文期待把這種找洞工作常態化；未來最值得對帳的，會是同樣資源下多修好了多少有效問題。

PHP2Shell 下一步：拿到可核對的修補證據

截至 2026 年 10 月 22 日本文查核，PHP 的這次安全發布版本如下。這是各分支的修補基準；使用發行版回補套件時，還要核對供應商對這兩個 CVE 的修補紀錄。

使用分支	10 月 21 日安全版本	要保存的證據
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 套件提供服務、兩個 CVE 是否已修補、服務程序是否已套用更新。若由自己的團隊管理，依官方與發行版指引更新，核對實際處理網頁請求的程序，再跑登入、上傳與主要業務流程的回歸檢查。終端機查到一個版本，還不足以代表所有網站工作程序。

官方說明 PHP 8.1 與更早版本已不再獲得 PHP 專案的例行更新，部分發行版或 LTS 供應商可能提供回補。舊系統應取得明確的套件修補證據，或安排遷移到受支援分支；不要把找到一份原始碼修補檔，視為正式服務已完成修復。

若目前依賴 WAF，Cloudflare 的公告仍要求更新 PHP，將 WAF 視為額外防線。PHP 官方也明確指出，緩解只能降低部分路徑的曝險，更新才是完整處理方式。對管理者，現在最有價值的成果，是一張列出網站、負責人、實際套件與修補驗收狀態的清單。

AI 能加快提出問題；可靠的防守，還要把每個有效問題送到可部署、可驗收的修補。先向主機商或團隊取得這張證據單，再決定下一步要增加多少自動化研究能力。