PHP2Shell（上）：飯店櫃檯的房卡機壞了，房間門鎖再強也沒用

PHP 在 10/21 緊急修補兩個未授權遠端執行漏洞 PHP2Shell。上篇用飯店房卡機比喻講漏洞在哪一層、受影響版本，以及 AI 在這次發現裡實際做了什麼。

先講一個比喻——這是簡化，後面會對回真實技術細節。

飯店櫃檯的房卡機平常很規矩，一張卡只寫入一間房的權限。但有人發現，只要故意一直塞奇怪的卡讓它超載，它做到一半就會當機。重開之後，上一張卡寫到一半的權限沒被清掉，吐出來的新卡就能打開不該開的房間，甚至是總控室。

重點有兩個：站在櫃檯前就夠了，不需要你是房客、也不需要密碼；而且無論每間房的門鎖做得多強，都救不了你——壞的是房卡機本身。

2026 年 10 月 21 日，PHP 專案緊急釋出安全性更新。兩個漏洞合稱 PHP2Shell（CVE-2026-109618、CVE-2026-109619），CVSS v4.0 皆為 9.2。在這個比喻裡，房卡機就是 PHP 引擎；網站自己的程式碼只是各房間的門鎖。門鎖再嚴，擋不住一台會吐出錯誤權限卡的機器。

這篇（上）講這台機器怎麼壞、為什麼 AI 時代特別容易挖到它。下篇講禁運怎麼破、攻擊怎麼來，以及你現在該怎麼檢查、怎麼修。

一、發生了什麼事

PHP 是許多網站背後的執行環境：WordPress、Drupal、Laravel，以及大量自架系統，請求進來後往往由 PHP 組出網頁再送回瀏覽器。依 W3Techs（2026/10/26）：在「可辨識伺服器端語言」的網站中，約 69%（精確值 69.2%）使用 PHP——這是語言市占，不是「現在還沒打補丁的主機數」。把市占直接講成受害規模，會誇大。

兩個漏洞的正式名稱大致是：

CVE-2026-109618：記憶體不足（OOM）時的損壞路徑（「RCE via OOM corruption」）
CVE-2026-109619：殘留全域狀態路徑（「RCE via stale global state」）

兩者都被評為未授權遠端程式碼執行（RCE）：攻擊者不必登入你的後台。Calif 寫最早受影響路徑可追溯到 PHP 5.4.0，影響面涵蓋約十四年的版本；官方正式修補版是 8.5.12／8.4.27／8.3.36／8.2.35。PHP 8.1 及更早不再由專案提供常規更新；官方另為 7.4、8.0、8.1 提供精簡原始碼後移植（無正式發行版）；7.3 以下含 PHP 5 無上游修補，只能升級。PHP 8.2 於 2026/12/31 EOL，之後也不再有安全更新。分數上：官方 CVSS v4.0 皆 9.2；NVD 等以 CVSS 3.x 呈現時，常見寫法是 109618 9.8、109619 8.1；外流貼文曾誤寫 10.0（PHP Foundation 事後確認錯誤）。更新後要重啟所有 PHP worker——像換完韌體還得把每台櫃檯機重開，常駐進程才會真的吃到新版。官方明說：設定上的暫時緩解不能讓系統變安全，唯一完整解法是更新。

名稱「PHP2Shell」在公開前一日左右已在社群流傳，之後 PHP Foundation、Wiz、OpenAI、CISA、Cloudflare 等文件也沿用。

二、根因：寫到一半的權限沒清掉

把比喻對回引擎（再次提醒：這是簡化）。

平常 PHP 處理完一個 HTTP 請求，會清掉這次請求用的記憶體與內部狀態，再接下一個請求。出問題的是「做到一半就中斷」的路徑：傳統上，當配置記憶體超過 memory_limit，或發生致命錯誤時，PHP 可能用 bailout／longjmp 直接跳出。結果可能是：

半初始化的記憶體——計數已經加了，內容卻沒寫完；清理時卻當成有效資料來用（大致對應 109618）。
請求結束後仍殘留的全域狀態——指標還指著已經釋放的堆積；長駐 worker（尤其 PHP-FPM）像同一台房卡機沒重置就接下一位客人，下一筆請求可能在重新初始化前用到殘留資料（大致對應 109619）。

對應房卡機：機器被塞到超載當機，重開後半寫入的權限沒清乾淨，下一張卡就可能開到總控室——不必講請求怎麼組，讀者只要知道「機器自己在邊界情況留下半成品」。

官方標 Apache mod_php 為最高風險：可以把它想成房卡機就嵌在櫃檯裡，客人一到櫃檯就能直接跟機器互動，而且即使啟動失敗，後續仍可能跑清理流程，在任何網站應用程式碼執行之前就中招。PHP-FPM 比較像櫃檯後方另開的窗口：啟動失敗時 worker 通常直接結束，比較不容易走同一條「同進程消費半成品」的路；但啟動成功之後的致命錯誤，worker 仍可能活著——109619 的部分路徑在 FPM 上已有驗證或源碼分析支持。對 109618，GitHub 安全公告寫的是：在 mod_php、預設限制下已用 HTTP 驗證 RCE；FPM「源碼上可受影響」，但尚未展示完整的 FPM exploit。

網站自己寫得多小心、外掛多新，都像把房門鎖換得再貴——修的是門鎖，不是房卡機。完整解法只有更新 PHP（換機器韌體）。官方列出的 ini 設定只能降低部分路徑的曝險，且明說不完整。

三、這顆雷：人的直覺導航，AI 降低「做成攻擊」的成本

PHP2Shell 不只是「又一個嚴重 CVE」，它剛好撞上我常寫的主題：AI 正在改寫資安節奏——但方向跟部分標題寫的不一樣。

時間線（有時刻者為台北時間；只有日期者標明 UTC 日期或來源日期）：

2004／2020／2024：Stefan Esser 早期「memory limit」類問題（Calif 回溯敘事，非本次 CVE 本體）；bug #78876；OSTIF／Quarkslab 審計（經 Sovereign Tech Agency 等資助）再次看到相關 OOM 問題，理論上可利用但未展示，修復停滯——PHP Foundation 後稱這是「結構性失敗」。
2026 年 5 月起：生態系安全團隊成立；期間也用過 Anthropic Claude Mythos（經 Alpha-Omega）、OpenAI Daybreak Red 等工具掃描或驗證。
7 月 30 日起：安全公司 Calif 在 OpenAI「Patch the Planet」架構下審計 PHP。
Calif 自述（一手）：約 8/1 挖到首批路徑；8/5 研究員 Ryan Austin（@lcfr_hax）在 X 發布發現雜湊；8/11 向 PHP 回報第一個 bug；8/14–15 提交並獲確認可重現的 RCE PoC；8/21 回報第二個 bug。關鍵框定：發現靠的是對 PHP 漏洞史與程式碼的熟悉（「know your target」），沒有特殊私有模型；LLM 有幫忙探索邊界情況、把模式泛化成可搜尋的技能，但不是「隨便 prompt 就能挖出所有 bug」。原話：「No model is simply capable of unearthing 'all bugs' with simple prompts. At least for now.」TechCrunch 的整理也寫：AI 主要協助把 bug 變成可利用路徑，主體仍是研究員既有知識。
Wiz：自述 8/19 發現、8/20–21 在 Drupal／WordPress 打出 RCE、8/24 正式回報；工具敘事包含 Gemini 4 Argon、GPT-5.6 Sol 等。
OpenAI：對外稱 Calif 用 GPT-5.6 Sol 在 8 月找到一版，自家團隊在 9 月找到更完整的版本；PHP Foundation 則寫 OpenAI 回報同一根因，並於 9/18 另報攻擊路徑。「OpenAI 第一次獨立回報」的精確日期，各一手來源並不一致，這裡保留歧異，不硬選一個日子。
10/16–17：Chainguard CEO Dan Lorenc 稱得知即將披露後，當晚用自家 AI harness 與前沿模型獨立復現，並於 10/17 加入協調頻道。

換句話說：同一類缺陷，在幾週內被多家、多次挖到，過程裡 AI 多半在場——但主導發現方向的是人對目標的熟悉；AI 真正壓低的，是「理論上有洞 → 做成可靠攻擊」這一段的成本。Axios 標題偏向「OpenAI 技術發現」；OpenAI 自家文也強調 frontier AI 搶在攻擊者之前——行銷敘事偏強，宜對照 Calif 一手寫作。計畫名稱以 OpenAI／Calif 一手為準，叫 「Patch the Planet」（TechCrunch 曾寫成「Hack the Planet」，與一手不符）。這會壓縮「祕密修補窗口」——知道的人變多，外洩面也變大。下篇會寫 10/20–21 禁運怎麼破；這裡先記一件：做成攻擊變便宜了，不代表公開網路上那些「一鍵 PoC」都是真的——大量是模型幻覺，下篇會回到 Marcus Hutchins 的觀察。

OpenAI 總統 Greg Brockman 在 X／公司長文裡把這次說成近兩個月的聯盟行動，也坦言披露尾聲不如預期（原文大意：原訂 10/22 釋出，細節提早外流，PHP 維護者改提前到 10/21）。政策端甚至出現「授權防禦方掃描、極端情況下遠端修補」的討論——那是更大的辯論，這裡只標記：PHP2Shell 已經被拿來當「AI 資安新常態」的案例。

四、上篇重點

房卡機＝PHP 引擎；門鎖＝網站自己的程式。壞的是引擎時，換門鎖不夠。
兩個 CVE，CVSS 9.2，未授權 RCE；修補版 8.5.12／8.4.27／8.3.36／8.2.35。
根因是 OOM／致命錯誤後的半成品狀態；mod_php 風險最高。
「約 69% 已知伺服器端語言的網站用 PHP」是語言市占，不是未修主機數。
影響可追溯到 PHP 5.4；正式修補只到 8.2–8.5，更新後要重啟所有 worker。
發現靠領域知識導航，AI 降低做成攻擊的成本——不是「AI 一鍵挖洞」；多獨立發現壓縮了協調披露的時間。

下篇預告：10/20 起 CVE 編號外流、Calif 誤公開示範影片、Chainguard 提前出含修補映像；AWS 蜜罐在公開前四天就看到嘗試；10/24 研究人員蜜罐確認在野成功拿到 shell。台灣資安署盤點約 2.8 萬個對外 PHP 站、政府約 200 個——下篇給可執行的檢查清單，以及這週能帶走的教訓。

繼續讀：PHP2Shell（下）

文中有具體時刻者，盡量標為台北時間（UTC+8），並在首次出現時對照 UTC。只有日期、沒有時刻的項目，沿用來源的 UTC 日期或官方標示的發布日。公開時刻在不同文件間約有半小時落差，下篇會註明。

來源

PHP，archive／安全性公告，2026/10/20–21：https://www.php.net/archive/2026.php
GitHub Security Advisories：GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp（php/php-src）
PHP Foundation，〈Today's PHP Security Release, and How We're Strengthening PHP Security〉，2026/10/21：https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
Calif，〈PHP2Shell: A tale of two PHP remote vulnerabilities〉：https://calif.io/php2shell/
Wiz，〈PHP2Shell〉，2026/10/21：https://wiz.io/blog/php2shell-php-rce
OpenAI，〈Coordinated disclosure of critical vulnerabilities〉，2026/10/21：https://openai.com/index/coordinated-disclosure-of-critical-vulnerabilities/
Greg Brockman（@gdb）X 長文／Article，2026/10/21