AI 率先發現 PHP2Shell 零日漏洞，接下來會怎樣？
AI Found the PHP Zero-Day First. Now What?
OpenAI 的 Patch the Planet 計劃中，AI 輔助研究人員在公開披露前數週發現 PHP2Shell，PHP 專案於 2026 年 10 月 21 日發布緊急修補。
文章梳理 PHP2Shell 從 AI 協助發現、跨組織修補到披露前出現利用的時間線，呈現防守窗口如何受協調與修補速度制約。
AI 最先發現 PHP 零日漏洞。然後呢？
2026 年 10 月 21 日，PHP 專案為兩個嚴重的遠端程式碼執行漏洞發布緊急修補程式：CVE-2026-109618 和 CVE-2026-109619，兩者統稱為 PHP2Shell。漏洞的 CVSS v4.0 評分為 9.2，影響過去十年發布的所有 PHP 版本，最早可追溯至 PHP 5.4，估計波及網絡上 70% 的網站。WordPress、Drupal、Joomla——預設設定下全部都容易受攻擊。
但真正的焦點並非漏洞本身，而是誰最先發現漏洞：在 OpenAI 的「Patch the Planet」計劃下工作的 AI 模型，早在公開披露前數星期便發現 PHP2Shell。保安公司 Calif 在 8 月使用 GPT-5.6 Sol 找出這些漏洞。Wiz Research 則獨立使用 Gemini 4 Argon、GPT-5.6 Sol，以及自家的 Wiz Atlas 工具，得出相同結論。在首宗影響互聯網大規模範圍的重大漏洞事件中，AI 輔助發現首次搶在攻擊者之前——但真是如此嗎？
漏洞詳情：記憶體損毀遇上過時狀態
PHP2Shell 包含四個漏洞，分屬兩個 CVE：
CVE-2026-109618（OOM 記憶體損毀）：當 PHP 在處理請求初始化期間於不合時宜的時刻耗盡記憶體，內部資料結構便會處於未完全初始化的狀態。清理程式碼會信任這些已損毀的狀態，從而引發釋放後使用漏洞。研究人員證明，在預設設定下，可透過 Apache mod_php 達成未經驗證的遠端程式碼執行。
CVE-2026-109619（過時的全域狀態）：致命錯誤會令內部指標在不同請求之間繼續存留。由同一 PHP 工作程序處理的後續請求，可劫持這些懸空指標，從而引發另一個釋放後使用漏洞。相關的記憶體洩漏變體可透過 PHPSESSID Cookie，從其他請求洩漏密碼、API 金鑰及憑證，即使沒有 session_start() 也能做到。
⚠️ 漏洞存在於 PHP 核心引擎，而非任何應用程式。即使是在受影響版本上執行「Hello World」指令碼，也容易受攻擊。單是更新 WordPress、Drupal 或你的框架並不能修復問題——你必須修補 PHP 本身。
攻擊面極為嚴重：研究人員已證明，可在最新的 WordPress、Drupal 和 Joomla 容器映像上，未經驗證便達成遠端程式碼執行。數小時內，GitHub 上便出現了一個名副其實的 php2shell 概念驗證漏洞利用程式，累積超過 900 個星標。任何持有 PoC 的人，實際上都沒有利用門檻。
AI 如何發現漏洞：Patch the Planet 的時間線
OpenAI 於 2026 年 6 月推出 Patch the Planet，作為其 Daybreak 網絡安全計劃的一部分。計劃由 Trail of Bits 及合作夥伴 HackerOne 和 Calif 共同建立，結合 AI 輔助漏洞研究與人類專家審核。截至 10 月，計劃已審查 50 個程式碼庫，並將 160 個修補程式合併至上游。
以下是 PHP2Shell 漏洞的發現經過：
2024 年：一名 PHP 核心開發人員在由 Sovereign Tech Agency 資助的 OSTIF/Quarkslab 審核期間，首次留意到記憶體耗盡錯誤模式。當時未有發現漏洞利用程式。修補工作其後停滯；PHP Foundation 後來稱這是其以共識為基礎的安全流程中的「結構性失誤」。
2026 年 7 月 30 日：應 PHP Foundation 要求，Calif 研究人員透過 Patch the Planet，開始使用 OpenAI 的 GPT-5.6 Sol 審查 PHP 原始碼。
2026 年 8 月 1 日：Calif 的 Ryan Austin 找出首個可被利用的漏洞。AI 模型不只是找到漏洞，還協助開發出可在多個 PHP 版本及部署設定中運作的漏洞利用鏈。
2026 年 8 月 19 日：Wiz Research 使用 Gemini 4 Argon、GPT-5.6 Sol 及 Wiz Atlas，獨立發現相同漏洞。兩天內，他們確認 Drupal 和 WordPress 存在未經驗證的遠端程式碼執行（RCE）漏洞。
2026 年 8 月 24 日：兩個團隊均向 PHP 安全團隊通報。OpenAI 透過 PHP Foundation 得知 Wiz 正同步進行相關工作，並協調統一應對。
2026 年 9 月 21 日：PHP 確認收到相關通報，並開始協調修補工作。
防守者的窗口期——還是如此嗎？
OpenAI 將 PHP2Shell 事件描述為「防守者窗口期」：先進 AI 模型在攻擊者利用漏洞前找出問題，讓社羣有時間準備修補程式、WAF 規則及緩解措施。這次協調應對涉及 PHP Foundation、Cloudflare、AWS、Akamai、Google、Microsoft、Vercel、Quarkslab，以及多個政府機構——從 NSA 和 FBI，到日本首相辦公室和歐盟 CERT。
Cloudflare 在原定於 10 月 21 日推出修補程式前，部署了臨時 WAF 規則。PHP Foundation 引入 OpenAI 的 Daybreak Red，用來驗證通報及漏洞重現環境。
看起來系統運作正常，只有一個問題。
⚠️ 反方觀點：Amazon 的 MadPot 蜜罐記錄到 PHP2Shell 利用嘗試，時間是 10 月 17 日——比公開披露早四天。這次嘗試來自商業匿名網絡。AWS 表示，「目前不清楚攻擊者如何在漏洞仍處於保密期時取得利用資訊。」防守者的窗口期可能在正式開啟前已遭突破。
這並非唯一一次外洩。CVE 詳情於 10 月 20 日外洩，當中時間安排及 CVSS 評分均有誤。Calif 意外發布了概念驗證影片。Chainguard 在協調發布前約六小時推出已修補的容器映像，讓攻擊者可以透過二進制差異進行逆向分析。
結果是：消息傳開後 45 分鐘內，Cloudflare 便報告有「數以萬計」次漏洞利用嘗試；兩小時內增至「數以十萬計」，當晚更達數以百萬計。AWS 確認該漏洞「已在實際環境中遭廣泛利用」。荷蘭和芬蘭為求謹慎，將政府網站下線。Archive.org 亦一度離線。
真正的轉捩點：AI 同時站在防線兩側
PHP2Shell 的重要性不止於眼前的應急行動，因為它證明AI 漏洞發現已達生產級水平。這不是基準測試分數，也不是受控評估，而是真實生產環境。
看看以下數字：
- 預計 2026 年將有 66,000 個 CVE，高於 2025 年的 48,000 個。事件應變與安全團隊論壇（FIRST）認為，增幅主要源於 AI 工具找出漏洞。
- 平均漏洞利用時間為負七日。Mandiant 的事故應變數據顯示，現時漏洞平均會在修補程式推出前一星期開始遭利用。
- 據報，Anthropic 的 Project Glasswing 在使用 Claude Mythos Preview 的最初幾個月內，發現超過 10,000 個高危或嚴重漏洞。
- OpenAI 的 GPT-5.6-Cyber 在完成進階網絡安全請求方面得分達 95%，而基礎模型 GPT-5.6 Sol 的得分為 1.5%。
- 在 Pwn2Own Berlin 2026，使用 AI 工具的研究人員在瀏覽器、AI 資料庫、編程 Agent 和企業應用程式中，發現了 47 個不同的零日漏洞。
雙重用途困境並非理論問題。正如 OpenAI 自己承認：「同樣的能力亦可協助攻擊者迅速開發攻擊工具和漏洞利用程式。」Bruce Schneier 將此形容為雙重用途悖論——只有在對手無法取得同等能力時，防禦者才佔有優勢。
而證據顯示，這種能力並未一直被拒諸門外。Google 的 Threat Intelligence Group 於 2026 年 5 月報告了一宗據其所述首次有公開記錄的 AI 生成零日漏洞利用事件——一次雙重認證（2FA）繞過攻擊，帶有明顯的 AI 痕跡（AI 幻覺生成的 CVSS 評分、教學式 docstring、教科書式 Python 格式）。他們在大規模利用發生前成功阻止攻擊，但能力門檻已被跨越。
社羣反應
安全社羣的反應交織着緊迫感和令人不安的認知。
在 Hacker News 上，Wiz 的漏洞披露帖文和 PHP Foundation 的回應均登上首頁。討論集中於協調工作的複雜程度——在消息封鎖期內消息外洩的同時，須將修補程式同步推送至 PHP 發行版本、Docker 映像檔和代管平台。多個討論串指出，已停止支援的 PHP 分支（7.4、8.0、8.1）沒有官方二進制發行版本，數以百萬計的伺服器只能依賴各發行版維護者回補修補程式。
在 Reddit 的 r/technology 上，Cloudflare 的漏洞利用數據——1.6K 個讚好、96 則留言——突顯了事件規模。留言內容包括「每個運行 cPanel 的共享主機都已經變成安全事故」，也有人討論 PHP Foundation 以共識為基礎的安全流程是否適合 AI 時代。
ℹ️ watchTowr 是首個公開確認漏洞確實存在的外部機構，並於 10 月 20 日、消息封鎖期正式解除前發布分析。他們的評估是：「沒有任何單靠設定的替代方案可以完全解決問題。」
Wiz 團隊與研究人員 Sagi Tzadik 和 Thai Duong (Calif) 一同深入探討的播客值得一聽，內容講述 AI Agent 如何處理針對不同版本調整漏洞利用方式；人類研究人員在實驗室中要花數月才能完成這項工作。
軍備競賽：數字一覽
更廣泛的背景凸顯 PHP2Shell 的重要性。這並非首次由 AI 協助發現漏洞，但這次事件首次引起主流公眾關注。
Google 的 Big Sleep 計劃在 2025 年底正式發布前，發現一個可被利用的 SQLite 漏洞（CVE-2025-6965）。據報，Anthropic 的 Project Glasswing 在 2026 年 4 月利用 Claude Mythos Preview 發現超過 10,000 個高危或嚴重漏洞。5 月，Google Threat Intelligence Group 記錄了首宗在實際攻擊中發現的 AI 生成零日漏洞利用攻擊——一次 2FA 繞過攻擊，程式碼中帶有明顯的 LLM 痕跡。6 月，自主網絡安全初創公司 depthfirst 花費約 $1,000 的運算成本，找出 21 個此前未公開的 FFmpeg 漏洞。
OpenAI 推出了愈來愈少限制、適合網絡安全研究的模型。GPT-5.5-Cyber 於 2026 年 6 月隨 Patch the Planet 推出。GPT-5.6-Cyber 於 8 月接棒，其「在漏洞利用開發方面降低防護限制」——處理進階網絡安全請求的完成率達 95%，而基礎模型只有 1.5%。包括 CrowdStrike、Cloudflare、Palo Alto Networks 和 IBM 在內的可信合作夥伴，透過 Daybreak Red 獲得使用權限。
這些數字説明，能力曲線正急速攀升。但缺乏流程的能力，只會讓人更快找到沒有人修補的漏洞。
這對你有何意義
如果你是開發者、網絡安全主管，或任何負責運行基礎設施的人，PHP2Shell 凸顯了新的營運現實：
1. 修補時限以小時計，而非以天計。
AWS 的建議直截了當：「針對面向互聯網的嚴重漏洞，應以小時計算修補和緩解所需時間。」10 月 17 日已遭利用，比漏洞披露早四天——這代表你的應對窗口在你甚至不知道有這個窗口前，便已開始。
2. WAF 優先、修補其次，已成新的處理次序。
Cloudflare 在漏洞披露前部署 WAF，拯救了無數網站。如果你的技術堆疊沒有配備能接收廠商威脅情報緊急規則的 WAF，從架構上而言，你已落後。
3. AI 加快漏洞披露，改變了嚴重程度分流。
當 AI 模型發現漏洞，披露到漏洞被利用的時間便會縮短。應將 AI 輔助的安全公告視為具有更高緊急性。傳統的 90 日披露窗口，假設攻擊者一方以人類速度發現漏洞。這個假設已不再成立。
4. 已終止支援的軟件，現已構成迫切危機。
PHP 7.4 至 8.1 已沒有官方二進制修補程式。公開 PoC 已獲 900 多個 GitHub 星標；在互聯網上運行已終止支援的 PHP，就如把大門敞開，還掛上「內有免費物品」的牌子。
5. 監察漏洞披露前的窗口。
Amazon 的 MadPot 入侵指標（IOCs）可追溯至 10 月 17 日。如果你還未檢查追溯至 10 月中旬的 PHP 日誌，現在就檢查。相關指標包括：異常的多部分請求及其後出現的記憶體限制錯誤、格式錯誤的 PHPSESSID Cookie、原因不明的 PHP 工作程序頻繁更替，以及網站根目錄中的可疑檔案。
💡 即時行動清單：更新至 PHP 8.5.12、8.4.27、8.3.36 或 8.2.35。更新後重新啟動所有 PHP 工作程序。部署針對多部分上載攻擊的 WAF 規則。搜尋追溯至 10 月 17 日的入侵指標。檢查是否有已終止支援的 PHP，並將其隔離或升級。暫時設定 session.upload_progress.enabled=0 作為權宜措施（這並不能封堵所有攻擊途徑）。
更宏觀的局面
PHP2Shell 並非孤立事件。這是迄今最明確的訊號，表明我們已進入一個 AI 發現漏洞的速度快於人類修復漏洞的速度 的時代。Cloud Security Alliance 説得很直白：在 Anthropic 的 Project Glasswing 計劃中，Mythos 發現的漏洞只有不到 1% 實際獲得修補。瓶頸不在於發現漏洞，而在於修復漏洞。
OpenAI 的 Patch the Planet 計劃試圖彌合這個差距，將 AI 發現漏洞與由人主導的大規模修補結合起來。Trail of Bits 的工程師會審查每項發現。Calif 和 HackerOne 負責分流處理及協調披露。這是正確的架構：AI 負責發現，人類負責核實和修復。截至 10 月，計劃已審查 50 個程式碼庫，並將 160 個修補程式合併至上游——這是有意義的開始，但相對於預計的 66,000 個 CVE，仍只是九牛一毛。
但 PHP Foundation 自身的事後檢討揭示了其中的脆弱之處。從首次注意到 OOM 模式，到推出修正方案，足足延誤兩年。以共識為基礎的安全團隊無法就取捨達成一致。協調披露的消息同時從三個方向外洩。於 2026 年 5 月成立的新 Ecosystem Security Team 是一大進步，但要促成這項結構性變革，竟然需要一場 CVSS 9.2 級的互聯網緊急事件。
AI 輔助漏洞發現，令防守方的工具箱大幅升級。但防守方的流程並未跟上。正如 Wiz 所言：「這標誌著 AI 的轉折點。」問題在於，依賴 PHP 的機構——換言之，也就是互聯網上的大多數機構——能否以應對轉折點所需的速度運作。
如果貴機構的安全策略仍然假設攻防雙方都以人類的速度發現漏洞，PHP2Shell 就是警鐘。攻擊者也有 AI。而從 10 月 17 日的漏洞利用可見，他們可能已經領先。
如欲瞭解更多 AI 時代的供應鏈安全資訊，請參閲我們對LiteLLM 供應鏈攻擊及OpenAI API 依賴風險的報道。
原文刊於 ComputeLeap
來源：DEV Community · dev.to