發生什麼：OpenAI 把一次 PHP 修補經驗寫成五階段提案
OpenAI 於 2026-10-21 發表〈Patch the Planet: global response coordination as agents uncover critical vulnerabilities〉。文章說，過去約兩個月，OpenAI 與維護者、研究人員和資安業者協調處理 PHP 的重大漏洞；PHP 維護者主導修補與發布，OpenAI、Wiz、Cloudflare 等提供研究、技術支援與協調。OpenAI 稱，研究團隊 Calif 透過其「Patch the Planet」計畫、使用 GPT-5.6 Sol 找到其中一個漏洞，Wiz 則獨立發現並回報兩個漏洞。
OpenAI 據此提出一套針對「廣泛使用、需要不只上游維護者採取行動」的重大漏洞框架，共五階段：一、驗證並修補上游漏洞，包括用前沿模型對修補做對抗測試、找繞過與變種；二、讓受影響組織先有時間行動，例如為舊版移植修補、主機商測試緩解、資安業者準備 WAF 規則；三、與政府夥伴協調，PHP 案中 OpenAI 稱聯繫了白宮「Super Intelligence Force」、國家網路總監辦公室（ONCD）、CISA 與國際夥伴；四、修補與揭露計畫穩定後，擴大通知發行版、主機商、應變團隊與營運者；五、公開指引並持續支援部署。
誰能提早知道，OpenAI 列出三項標準：保護角色、所需行動時間、處理敏感資訊的能力，同類組織同等對待，最終由維護者決定。若出現野外利用、外洩、公開修補洩露漏洞細節，或修補停滯提高用戶風險，就應與維護者重新評估時程。文章最後就揭露窗口長度、分階段與廣泛通知的取捨、舊版套件修補，以及「政府或營運者在失去管理權限後是否該主動修補自己管理的系統」等問題公開徵求意見。
觸發事件：PHP2Shell 兩個 CVSS 9.2 漏洞
PHP 官方於 2026-10-21 發布 8.5.12、8.4.27、8.3.36 與 8.2.35 安全版本，修補 CVE-2026-109618 與 CVE-2026-109619；兩份 GitHub 安全公告都標為 Critical、CVSS v4.0 基本分 9.2，向量含「攻擊複雜度高、需特定前提」（AC:H/AT:P），但不需權限或使用者互動。CVE-2026-109618 源於記憶體不足時以 longjmp 中止請求，留下半初始化的請求資料；公告稱已在預設設定的 mod_php 上確認未經驗證的遠端程式碼執行，FPM、FrankenPHP、LSAPI 評估為可能受影響。CVE-2026-109619 則是 worker 保留指向已釋放記憶體的全域狀態，屬 use-after-free。
PHP 官方稱更新是唯一完整修補，並列出部分緩解設定，例如停用 session.upload_progress、PHP 8.5 關閉 fatal_error_backtraces；PHP 8.1 以前已不再受官方支援，安全團隊另提供 7.4、8.0、8.1 的最小原始碼移植。Wiz 的文章稱，第一個漏洞於 2026-08-19 發現、08-24 回報 PHP、09-21 獲確認；研究使用 Wiz Atlas、Gemini 4 Argon 與 GPT-5.6 Sol，並稱過去十年發布的 PHP 版本都至少受其中一個漏洞影響。換言之，「AI 找到漏洞」在這個案例裡涉及多家模型與多個研究團隊，不能歸功於單一模型。
揭露前 4 天已有人試打：AWS 的蜜罐紀錄
Amazon 資安長 CJ Moses 於 2026-10-21 在 AWS Security Blog 發文表示，Amazon Threat Intelligence 的 MadPot 蜜罐遙測中，有一筆 PHP2Shell 利用嘗試可追溯到 2026-10-17，來源是商業匿名化網路的 IP；而 PHP 禁運解除時間是 10-21 14:00 UTC。AWS 也說，10-21 約 02:00 UTC 起陸續出現多個概念驗證（PoC）與更多來自匿名化基礎設施的嘗試。
AWS 明言，攻擊者如何在揭露前取得漏洞資訊仍不清楚，這些嘗試在真實系統上能否成功也不明。它建議以「小時」衡量重大對外漏洞的修補時程，從至少 10-17 開始回溯調查，例如在網站日誌搜尋含 PHP_SESSION_UPLOAD_PROGRESS 的 POST 請求。
讀者影響：誰需要動作
對自架網站、主機商與使用 WordPress、Drupal 等 PHP 應用的團隊而言，最直接的動作是升級到上述修補版本，或向發行版與 LTS 供應商確認是否已有移植修補；在無法立即升級時套用 PHP 官方列出的緩解，並依 AWS 建議回查 10-17 以後的日誌。加密貨幣交易所、錢包與項目方的網站和後台若跑在 PHP 上，同樣在範圍內，這類服務一旦遭遠端執行程式碼，影響可能延伸到 API 金鑰與熱錢包操作環境。
AI 觀點分析與推論
AI 觀點：瓶頸已從「找到漏洞」移到「禁運守得住多久」
我傾向認為，這份框架最有價值的部分不是五個階段本身，而是 OpenAI 自己列出的「重新評估時程」條件。PHP2Shell 一案中，Wiz 用了多家 AI 工具，OpenAI 側也有團隊用 GPT-5.6 Sol 找到漏洞；同一個漏洞被兩組人獨立找到，再加上 AWS 在揭露前 4 天看到利用嘗試，顯示當前沿模型普及後，「只有防守方知道」的假設會愈來愈短命。若找到漏洞的成本持續下降，則禁運期越長、知情圈越大，被第三方獨立發現或外洩的機率也越高。
受益者是有資源參與早期通知的大型主機商、雲端與資安業者；吃虧的可能是沒被列入名單的中小營運者與舊版使用者，他們只能在公開那天起跑。框架把「誰先知道」交給維護者判斷，並把政府單位放進流程，這能加快關鍵基礎設施修補，但也讓「誰被通知、誰沒有」更需要透明紀錄；OpenAI 徵求意見中提到的「失去管理權限後主動修補」，則是爭議最大的一題，可能涉及未經授權存取的法律界線。
反面情境是：若 10-17 的嘗試最後證實只是無效探測，或來源是其他研究者的掃描，那麼這次禁運大致成功，框架的分階段通知就有成效。會讓我改變判斷的訊號有三個：AWS 或 PHP 後續說明 10-17 嘗試的成因；其他 AI 實驗室（例如 Google）是否採用相近流程；以及下一個 AI 發現的重大漏洞，從回報到公開的時間是否明顯縮短。
限制與下一步
五階段框架是 OpenAI 單方提出並徵求意見的提案，未見 PHP 專案、CISA 或其他 AI 公司表態採納。漏洞發現經過、使用的模型與時間線分別來自 OpenAI 與 Wiz 的自述；揭露前利用嘗試來自 AWS 的蜜罐觀測，AWS 未指認攻擊者，也未判定是否外洩。Wiz 文中「影響全球 70% 網站」等說法屬該公司描述，本文未採用為獨立統計。後續值得觀察的是 PHP 或相關單位的事後檢討、主要 Linux 發行版與主機商的修補進度，以及 OpenAI 是否依回饋修訂框架。
