PHP2Shell：AI 挖出影響 7 成網站的 PHP 漏洞
PHP 5.4 到 8.5 都在影響範圍內，兩個 CVSS 9.2 的遠端執行漏洞逼全球網站一天內更新。先找到的不是攻擊者，是兩組用 AI 讀原始碼的團隊。
2026 年 10 月 21 日，全球有相當比例的網站在同一天被要求立刻更新。荷蘭的政府入口網站 Overheid.nl、芬蘭的政府服務、法國內政部的數個網站陸續下線，維基媒體基金會關閉了多項服務，Internet Archive 也短暫停止運作。英國 NCSC 與歐盟 CERT-EU 的建議很直接：如果沒辦法馬上更新，就先把系統關掉。
起因是 PHP 裡的兩個漏洞，Wiz 把它們命名為 PHP2Shell。對一般讀者來說，真正值得停下來看的不是漏洞本身，而是它被誰找到的——這次搶在攻擊者前面翻出問題的，是兩組拿 AI 去讀原始碼的團隊。
Photo by Killari Hotaru on Unsplash
PHP2Shell 到底是什麼
PHP2Shell 指的是兩個編號 CVE-2026-109618 與 CVE-2026-109619 的記憶體安全漏洞。兩者在 CVSS 4.0 都被 PHP 官方評為 9.2 分，屬於未經驗證就能遠端執行程式碼（RCE）的類型——攻擊者不需要帳號密碼，只要送出特製的請求，就有機會在伺服器上執行指令。資安公司 watchTowr 甚至把其中一個評為滿分 10.0。
影響範圍是這次事件的核心。受影響的版本從 PHP 5.4 一路到 8.5，而 5.4 是 2012 年發布的。依 W3Techs 的統計，在可辨識伺服器語言的網站中約有 69% 使用 PHP；換句話說，接近七成的網站在修補之前都落在影響範圍內。這裡面包含 WordPress、Drupal、Joomla 架設的站台，也包含 cPanel、Plesk 這類主機管理面板，以及把 PHP 包在裡面的各種設備與應用程式。
PHP 官方在 10 月 21 日釋出 8.2.35、8.3.36、8.4.27、8.5.12 四個修補版本，另外替已經終止支援的 7.4、8.0、8.1 分支提供原始碼修補，但沒有官方編譯好的套件。官方同時說明：臨時的設定調整只能降低風險，不能取代更新。PHP 基金會的 Volker Dusch 形容這是 PHP 十多年來最嚴重的一次；Wiz 則把它拿來和 Heartbleed、Log4Shell 相提並論。
先找到它的不是駭客，是模型
第一個漏洞是加州資安公司 Calif 的 Ryan Austin 在 2026 年 8 月發現的。他當時正在審閱 PHP 的原始碼，用的是 OpenAI 的 GPT-5.6 Sol，整個審閱工作屬於 OpenAI 名為「Patch the Planet」的資助計畫。Austin 事後強調，他只用了一般人都能取得的模型，沒有特殊工具。
幾週之後，Google 旗下的 Wiz 獨立發現了同一組問題，使用的是 Gemini 4 Argon、GPT-5.6 Sol，以及自家的 Wiz Atlas。PHP 的資安公告同時列出了 Calif、Wiz 與 OpenAI。
更值得玩味的是一個細節：其中一個漏洞背後的記憶體錯誤，早在 2024 年就有 PHP 核心開發者在一次審查中注意到。它最後沒有被修掉，原因是團隊對修法沒有共識，而且當時沒有人示範得出可用的攻擊手法。問題一直躺在那裡，直到有人用模型重新把整份程式碼讀了一遍。
這說明了 AI 在這件事上真正的角色。它沒有發明新的攻擊方式，它做的是把「有人得花幾個月逐行讀完一座三十年老程式碼庫」這件成本極高、回報極不確定的工作，壓縮成可以反覆執行的流程。Austin 自己的說法相當克制：沒有哪個模型靠幾句提示就能挖出所有漏洞，至少現在還不行；他認為熟悉 PHP 的歷史包袱，比換哪個模型更關鍵。
那一週實際發生的事
這次揭露的過程並不平順。原訂的公布時間是 10 月 21 日 14:00 UTC，但細節先在 Hacker News 外流，watchTowr 的文章與 Calif 不慎釋出的概念驗證影片也跟著流傳，官方只好把發布時間往前挪到 13:34 UTC。
在補丁出來之前，防守與攻擊已經開始賽跑。Cloudflare 在 10 月 21 日 03:02 UTC，也就是正式揭露前約九小時，替所有客戶（包含免費帳號）啟用了暫時的 WAF 規則。更值得注意的是 Amazon 威脅情報團隊的說法：他們在 MadPot 誘捕系統中找到一筆 10 月 17 日的利用嘗試紀錄，比揭露早了四天。美國 CISA 則表示在 10 月 21 日當下尚未觀察到實際利用。
另外還有第三個漏洞 CVE-2026-115560 被一併揭露，但 PHP 基金會決定不做緊急修補，只發布資訊性公告，留待下一次例行版本處理。原因是觸發條件相當罕見：應用程式要先把 session.serialize_handler 設為 php_binary 或 php_serialize，接著在執行期用 ini_set() 改回 php，而且要在呼叫 session_start() 之前，同時還得開啟 session 上傳進度功能。想先處理的人，可以暫時把 session.upload_progress.enabled 設為 0。
三個值得記下來的觀察
第一，防守方確實領先了，但領先的幅度很薄。OpenAI 把這次事件稱為近期最具影響力的資安事件之一，並認為它證明了 AI 可以在攻擊者之前找到問題。從結果看，補丁確實趕在大規模攻擊之前上線。但 Amazon 的 10 月 17 日紀錄提醒了另一件事：同樣的工具在另一端也在運轉，而揭露前的那幾天，是雙方都知道、只有一方能修的空窗。
第二，「能找到漏洞」和「能告訴你有沒有中」是兩回事。OpenAI 事後開源了一支 php2shell-checker，讓站長自行檢查。實際測試的結果卻顯示它的用處有限：一位開發者拿它掃了 65 個真實網站，全部回傳 UNKNOWN，其中 64 個根本沒在 HTTP 標頭裡送出 PHP 版本。原因不難理解，這支工具只做一件事——讀取 Server 與 X-Powered-By 標頭裡的版本字串，不送任何攻擊性探測。而現在多數網站早就不對外公布版本號。更麻煩的是，各家 Linux 發行版常會把修補回溯到舊版號而不改版本字串，光看版號兩個方向都可能判斷錯。真正可靠的檢查，還是得在主機上看實際執行的 PHP 版本與套件更新紀錄。
Photo by Fujiphilm on Unsplash
第三，資源的不對稱被攤開來看。《衛報》在報導中提到一組對照：撐起全球約七成網站的 PHP，背後的 PHP 基金會只有 13 名員工，主要靠捐款運作；而同一時間，AI 研究吸收的是以十億美元計的投資。這次的修補之所以能在一天內完成，靠的是基金會、cPanel、CloudLinux，以及像 Ondřej Surý 這樣替舊版本準備安裝包的志工。OpenAI 宣布投入 10 億美元，提供其 Daybreak 資安計畫的補貼存取給資源不足的防守方，方向是對的；但工具變強，不會自動讓維護人力變多。
對一般企業來說，該做的其實不多
如果公司有官網、電商或任何對外系統跑在 PHP 上，這次需要確認的事情其實相當具體：
- 先問主機商或維護廠商「現在跑的是哪個 PHP 版本」。不是問有沒有更新，是問版本號。對照 8.2.35、8.3.36、8.4.27、8.5.12 這四個版本，低於對應分支的修補版就代表還沒處理完。
- 確認版本是不是還在支援期。7.4、8.0、8.1 這三個分支只有原始碼層級的修補，沒有官方套件。WordPress 官方也提醒，8.2 之前的版本已經不再收到安全性更新——這類站台這次不只是更新，是該排升級了。
- 別只靠線上掃描工具的結果。如同前面提到的，從外部讀標頭的判斷方式容易給出「查不到」或誤判。要確認，最後還是得回到主機上看。
- 把這次當成一次盤點。多數公司真正的風險不在主站，而在那些還活著、卻已經沒人維護的舊系統：幾年前做的活動頁、內部用的小工具、測試站。它們通常跑在更舊的 PHP 上，而且沒有人會想到要更新。
這件事之後
PHP2Shell 不會是最後一次。這已經是幾個月內第二次由 AI 找出的網路軟體漏洞引發全球更新潮，前一次是 7 月的 WordPress 系列問題。OpenAI 也預期這類發現的數量會明顯增加。
對企業而言，實務上的變化大概會是這樣：過去「重大漏洞」是數年一遇的事件，更新節奏可以用季度來安排；接下來它更可能變成一種需要固定處理的日常——知道自己有哪些系統、各自跑在什麼版本上、誰負責更新、多久內更新得完。工具端的進步已經在發生，而且不在企業手上；能自己控制的，是被通知的那一天到真正修好之間，要花多久。
這次全球有不少組織選擇直接把服務關掉等修補。那是一個務實的決定，前提是知道自己有哪些服務要關。