PHP 兩個漏洞潛伏逾十年，AI 輔助研究人員數周內構造出可行漏洞利用

週三，芬蘭將其政府網站下線。荷蘭議會網站陷入黑屏。愛丁堡市議會網站消失無蹤。維基百科部分頁面停止載入。甚至有幾個 BBC 節目頁面也無法瀏覽。

原因是 PHP 出現兩個程式錯誤。這種語言一直在背後支撐網絡上的大部分網站。易受攻擊的程式碼已存在超過十年。之後，AI 輔助的研究人員在幾星期內將其轉化為可用的攻擊手法，事件隨即展開。

這就是 PHP2Shell 的故事。我認為這是今年最有意思的網絡安全故事，因為正反雙方即將使用完全相同的手法。

首先，究竟出了甚麼問題

據 Wiz 的估算，PHP 支撐約 70% 的網站。WordPress、Drupal、Joomla、MediaWiki（維基百科背後的軟件），以及大量共享主機服務和控制面板，都建基於 PHP。如果你使用 WordPress 或 WooCommerce（我採用的技術堆疊），你的伺服器便會執行 PHP。

10 月 21 日，PHP 團隊修補了兩個嚴重漏洞：CVE-2026-109618 和 CVE-2026-109619，兩者的 CVSS 評分均為 9.2。研究人員將它們命名為 PHP2Shell，名稱已點出關鍵：未經驗證的遠端程式碼執行。攻擊者不需要登入，也不需要你的程式碼有漏洞。漏洞存在於 PHP 本身，因此即使是以易受攻擊版本執行的「Hello World」應用程式也可能受到攻擊。

這種技術構思巧妙得令人不安。PHP 遇上致命錯誤時，例如在處理請求期間記憶體耗盡，可能會留下受損的內部狀態。工作程序仍會存活，而同一工作程序處理的下一個請求可能繼承殘留狀態。只要將這些環節串連得當，就能利用 use-after-free 原語實現完整的程式碼執行；研究人員已在預設安裝的 WordPress、Drupal 和 Joomla 上示範這種攻擊。

另一個漏洞的危害則更隱蔽。它讓攻擊者可以遠端讀取 PHP 工作程序的記憶體，包括其他用戶請求中的密碼、權杖和 API 金鑰，而竊取的資料會包在 PHPSESSID Cookie 內傳回。Wiz 將之與 Heartbleed 相提並論，這樣比較確有道理。不需登入，也不需要執行程式碼。只要客氣地提出要求，伺服器便會把機密交出來。

圖片：Wiz Research

讀來像小説的部分

這段易受攻擊的程式碼經過人類審閲，卻仍存在了十多年。原因另有所在，並非沒有人關心。據 Tom's Hardware 報道，PHP Foundation 自 2024 年起已知道底層程式碼有問題，但無法找出利用方法或修補方案。攻擊鏈過於複雜，難以示範：步驟太多，還需要繁複地調整記憶體配置。

之後，兩個團隊各自獨立地使用前沿 AI 模型研究這個問題。

Calif 是一家網絡安全測試公司，參與 OpenAI 的「Patch the Planet」計劃。應 PHP Foundation 要求，該公司於 7 月 30 日開始使用 GPT-5.6 Sol 審查 PHP。據 Tom's Hardware 報道其轉述的 OpenAI 説法，研究員 Ryan A. 於 8 月 11 日找出可被利用的漏洞，OpenAI 研究人員亦在同日發現該漏洞。
Wiz 則另行使用其 Atlas agent、Google 的 Gemini 4 Argon 及 GPT-5.6 Sol 找到相關漏洞。Wiz 記錄的時間線是：8 月 19 日首次發現，翌日在 Drupal 上成功實現 RCE，再翌日在 WordPress 上成功實現 RCE，並於 8 月 24 日前將所有問題報告給 PHP。

Wiz 的説法一直留在我腦海中：「一名研究人員在一星期內完成的工作，過去一支世界級團隊要花上數月才能完成。」這些漏洞並非新發現。改變的是，利用這些漏洞已不再難以實行。

接着資料外洩，攻擊者迅速採取行動

原定採取平穩、協調的披露安排。修補程式和技術詳情原定於 10 月 22 日公佈，並會預先向防守方簡報。事情卻沒有按計劃發展。

10 月 20 日，漏洞詳情在社交媒體上外洩，發布時間因此提前了一天。另一件事則更令人擔憂：Amazon 表示，在公開披露前四天已發現黑客試圖利用該漏洞，並形容這些漏洞「現正於實際環境中遭到廣泛利用」。

有兩點需要如實説明。第一，這些是 Amazon 向《金融時報》和 Ars Technica 報告的利用企圖；CISA 表示，截至其 10 月 21 日的公告，尚未觀察到漏洞遭利用，而我目前也未見有任何已確認的入侵事件被歸因於這些漏洞。有人嘗試利用漏洞，不等於成功入侵。第二，「AI 最先發現」這種説法需要謹慎看待。這是OpenAI 的説法，而且指的是發現漏洞：私下處理窗口確實存在，從 8 月發現漏洞到 10 月推出修補程式，約有兩個月。但公開窗口實際上幾乎為零。Amazon 表示，公開披露前四天已有人試圖利用漏洞，因此全世界得知消息時，攻擊者已經開始行動。

無論如何，星期三的情況相當戲劇化。NSA、CISA 和 FBI警告各機構立即安裝修補程式，否則便應將系統離線；NSA 表示，這些漏洞「往往會直接連接到伺服器的檔案系統或資料庫」。英國 NCSC、CERT-EU，以及澳洲和日本的機構也發布了類似建議。據 BBC 報道，日本首相親自在 X 發文，敦促民眾檢查自己的網站是否使用 PHP。當政府首腦都親自發布修補程式相關訊息，這確實是大事。

説句實話：AI 並沒有單靠自己扭轉局面

很容易把這件事看成 AI 的勝利故事，但事情並不完全是這樣。

按 OpenAI 的説法，防守方在發現漏洞方面先行。OpenAI 稱這段領先時間為「防守方窗口期」，並利用這段時間協調出令人印象深刻的應對措施：在公開披露前，Cloudflare、AWS、Akamai 和 Fastly 已準備好 WAF 規則；政府機構亦已參與其中，另承諾提供 10 億美元，補貼資源不足的防守方使用安全工具。

但 Wiz 也直言不諱地指出另一面：「有了 AI，這不再是障礙。LLM 可以協助調整漏洞利用方式，以配合不同 PHP 版本、設定和記憶體配置。」讓 Calif 和 Wiz 能夠製作這些漏洞利用程式的能力，也正是令這些漏洞如今變得危險的能力。十年來，這些漏洞之所以受到防護，純粹是因為利用它們極其困難。這道防線如今已不復存在，防守方和攻擊者都一樣。

此外，規模方面有一點需要注意：「70%」這個數字是 Wiz 對 PHP 在網站中所佔比例的估算，而BBC 指出無法核實這個數字。使用比例也不等於可被利用的比例，而且至今沒有人公佈仍未安裝修補程式的伺服器數量的可靠統計。即使如此，無論採用哪種衡量方式，受影響範圍都極為龐大。

我實際會怎樣做（枯燥的檢查清單）

如果你有任何 PHP 系統在運作；如果你自行託管 WordPress 或 WooCommerce，這就適用於你：

修補執行環境，而非應用程式。更新 WordPress 在這裏毫無作用。請安裝 PHP 8.5.12、8.4.27、8.3.36 或 8.2.35，然後按照官方指引重新啟動 Apache、PHP-FPM 及任何長時間執行的 PHP 工作程序。
如果無法修補，就讓系統離線。這不是危言聳聽：CISA 表示，無法更新，或仍在使用 PHP 8.1 或更早版本（這些版本不會獲得修補程式）的機構，應讓以 PHP 為基礎的系統離線，直至能夠更新為止。NSA 和 NCSC 也提出了相同建議。
WAF 是安全帶，不是修補方案。CISA 表示，WAF「或可在系統更新前提供一定程度的保護。」AWS、Cloudflare 和 Akamai 均推出了託管規則。請在修補期間使用，而不是以此取代修補。
找出 PHP 藏身的每個地方。PHP 可能藏在託管平台、控制台、監察工具和從未提及 PHP 的設備裏。Sophos 向 BBC 表示，難處不在於修補，而在於找出每一個正在執行 PHP 的地方。如果你想協助盤點，OpenAI 推出了以 Codex 技能形式提供的版本檢查器。
檢查是否有人已率先入侵。Amazon 報告有正在進行的漏洞利用嘗試。Wiz 的網誌列出相關跡象：異常的多部分請求，其後出現記憶體限制錯誤、反覆出現 HTTP 500 錯誤、異常龐大或格式錯誤的 PHPSESSID Cookie，以及原因不明的 PHP 工作程序重新啟動。

更大的問題

Wiz 將 PHP2Shell 描述為 AI 時代的 Heartbleed 或 Log4Shell 時刻，我認為這個説法正確，但理由與大多數報道所説的不同。那些漏洞讓我們明白，互聯網依賴無人審核的共用基礎設施運作。這次的漏洞則讓我們明白，「難以利用」從來不是一種安全屬性。那只是一項人力成本，而 AI 令這種人力成本變得低廉。

OpenAI 表示，預計類似的發現會在未來幾個月大幅增加。我相信他們。未有答案的問題是，誰會最先發現下一個漏洞，以及當雙方使用相同模型時，防守方窗口還能維持多久。

你認為，這個防守方窗口能否維持，還是現在已是它最寬的時候？如果你在任何地方執行 PHP，星期三有多難熬？

資料來源：Wiz Research、OpenAI、php2shell.com、CISA、NSA、BBC、Ars Technica / FT、TechCrunch、Tom's Hardware、AWS Security Blog。Wiz 的公告文章：https://infosec.exchange/@wiz/117479149813368302