PHP2Shell 安全披露時間表提前兩日外洩，AI 加速漏洞挖掘考驗協調流程

作者：Nokka (นก-กา) | 資料核實日期：2026年10月24日

本文由 AI（deepseek-v4.1-flash · 模型供應商：ollama-cloud）透過 Hermes Agent 撰寫，並由人員監督及進行品質檢查 - Nokka (นก-กา)

2026年10月21日，PHP 團隊推出四個新版本，修補兩個嚴重級別的漏洞。在特定條件下，陌生人可利用這兩個漏洞在伺服器上執行程式碼

我感興趣的不是漏洞本身，而是10月20日——比原定日期早兩天、比實際版本發布早一天——公告計劃開始逐步瓦解的那一天

這是協調披露在 AI 工具大幅加快漏洞搜尋速度的時代的一個很好的案例研究；以往足夠的時間框架，如今已經不再足夠

PHP 核心中的兩個漏洞

兩個漏洞的 CVSS 評分均為 9.2，並列為嚴重級別 [1][2][7]

CVE-2026-109618 是在不恰當時機發生記憶體耗盡所致。如果某個請求剛好碰上 memory_limit 上限，PHP 可能會留下尚未完成建立的內部資料，之後卻將其視為有效 [1]

結果是記憶體損毀；在採用 mod_php 的 Apache 伺服器上，未經驗證的攻擊者甚至可以在應用程式程式碼開始執行前觸發這個問題，而且研究人員已用預設設定示範完整的程式碼執行 [1][5]

CVE-2026-109619 源於全域狀態未有重設。如果在不恰當時機發生致命錯誤，內部狀態可能仍指向上一個請求所用的記憶體，於是同一個 worker 處理的下一個請求便會使用已被釋放的記憶體 [1]

漏洞報告者示範瞭如何在實際運行於 Apache mod_php 的應用程式上遠端執行程式碼 [1][6]

PHP 團隊亦指出，PHP-FPM 也已確認可透過應用程式層級的途徑執行程式碼，不限於 mod_php [1]

這兩個漏洞令人擔憂之處，在於它們位於幾乎每個請求都會接觸的部分——記憶體管理和錯誤處理，而非外掛程式或附加程式庫 [1]

失控的時間表

官方原定於2026年10月22日 14:00 UTC 發布版本，即本地時間21:00 [1]

這項安排提前兩天告吹

10月20日約 15:00 UTC，有人在論壇和社交媒體上發布了兩個 CVE 編號，並附上錯誤的發布時間，以及錯誤的 CVSS 評分 10.0；實際評分是 9.2 [1]

好消息是，當時尚未有技術細節外流

10月20日 19:30 UTC，PHP 團隊決定提前發布公告，並把版本發布日期由10月22日改為10月21日，時間不變 [1]

他們只提前一天發布，而非立即推出，是因為發行商尚未完成套件打包；若立即發布，許多用戶便沒有簡便的更新途徑 [1]

10月20日約 20:00 UTC，漏洞報告團隊之一的安全公司 Calif 不慎公開了一段影片。影片展示了可針對多個目標運作的 PoC，並披露了少量額外細節 [1]

影片雖然已被刪除，但副本在社交媒體上流傳，並促使其他人跟進製作 PoC，直至21日 [1]

10月20日約 23:00 UTC，PHP 團隊發送給部分重要基礎設施供應商的緩解風險指引，可能亦已外流 [1]

10月21日 07:41 UTC，Chainguard 向公眾發布了已修補的映像檔，比公告時間早逾六小時 [1]

為何已修補的映像檔會構成問題

Chainguard 與其他發行商一樣，提前取得修補程式，讓其用戶可以在公告發布後立即更新 [1]

但提前發布映像檔，代表任何人都可以拿已修補的二進制檔研究修補內容；當時其他 PHP 用戶仍在等待公告發布 [1]

PHP 基金會指出，此舉是單方面打破保密期，亦罔顧相關人員數星期以來的工作 [1]

在我看來，這是時間表外洩的典型途徑：完全不需要任何技術細節，只要有已修補的版本可以用來比對就行

PHP 團隊表示，在公告發布時，他們尚未從外洩的 PoC 中找到可實際運作的 exploit [1]

但「尚未找到」不代表沒有人能做到，也不應成為延遲更新的理由

為甚麼這兩個漏洞修補得這麼慢

我認為，公告中最坦率的部分是這一段，因為 PHP 團隊親自寫道：「延誤是結構性失敗」[1]

回到 2024 年，PHP 多年來首次接受外部安全審查，由 Sovereign Tech Agency 資助、經 OSTIF 安排，並由 Quarkslab 執行 [1]

在修補 Quarkslab 報告的一個問題期間，一名獲基金會資助的核心開發人員發現了 OOM 問題的初步跡象，這個問題後來成為 CVE-2026-109618 [1]

2024 年時，團隊推測這個問題可能可以被利用，但當時尚未找到實際攻擊路徑，而且有其他更明顯的問題掩蓋了它 [1]

修補時必須在幾種方案中作出選擇：犧牲向後相容性、引入新的拒絕服務漏洞，或要求第三方擴充功能相應修改程式碼，而要協調這些修改幾乎不可能 [1]

安全團隊採用共識決策，因此始終無法選定方案，修補工作也在數月間時斷時續 [1]

多方幾乎同時提交報告，成為事情的轉捩點

• 2026 年 7 月 30 日，PHP 專案加入 Patch the Planet，Calif 公司開始檢查程式碼 [1]
• 8 月 11 日，Calif 的 Ryan A 報告了一個無需任何條件即可觸發的遠端程式碼執行漏洞，根源與 OOM 問題相同 [1]
• 8 月 24 日，Wiz 報告了其他攻擊向量 [1]
• 9 月 18 日，OpenAI 再報告一批其他攻擊向量 [1]

自 8 月 11 日起，修補 OOM 問題便成為基金會安全團隊所有人的首要工作 [1]

AI 令雙方都加快步伐

Wiz 將整合這兩個漏洞的腳本命名為 php2shell，並指出 PHP 支援全球約 70% 的網站，而過去十年推出的每個版本至少都有一個漏洞，追溯至 5.4 [3]

Wiz 寫道，這類漏洞在 PHP 程式碼中隱藏了十多年，但要證明它們可以被利用，需要非常複雜的步驟，已接近人類研究人員實際能力的極限 [3]

頂尖 AI 模型降低了這道門檻，令舊問題變成可實際運作的 exploit [3]

PHP 團隊也使用 AI，包括以 Claude Mythos 配合 Alpha-Omega 掃描，以及使用 OpenAI 的 Daybreak Red 工具審查報告和 PoC [1]

副作用是收到的報告大幅增加。團隊表示，自 7 月 1 日起，他們收到超過 100 份報告，結果屬於重複報告、無法重現，或並非真正的漏洞 [1]

AI 有助將根源相同的報告分類，但每次仍由人作出決定，所有修補程式也由人撰寫 [1]

我認為，這就是所有大型專案正面對的局面：找出 bug 的工具變得更便宜、更快捷，但作決策的人數仍然不變

PHP 團隊已作出的改變

團隊正調整應對流程，讓基金會領導層在遇到修補方案涉及重大取捨的漏洞時，可以更快介入協助作決定 [1]

在此之前，今年已經有多項變動

• 2026 年 5 月，成立 Ecosystem Security Team，與安全團隊合作，負責漏洞分流、協調及安全強化 [1]
• 7 月，Alexandre Daubois 加入，協助分流及處理報告 [1]
• 9 月，Daniel Scherzer 加入，負責安全強化工作 [1]
• 團隊改變了決策方式，容許以多數票作決定，不再要求所有人達成共識 [1]

如果你負責管理 PHP 伺服器

已修補的版本為 8.5.12、8.4.27、8.3.36 和 8.2.35 [1][4]

# ดูรุ่นที่รันอยู่จริง รวมถึง SAPI ที่ใช้
php -v
php -i | grep -i "server api"

# Debian / Ubuntu
apt list --installed 2>/dev/null | grep -E "^php[0-9.]+"

# RHEL family
rpm -qa | grep -E "^php"

如果結果顯示為 Apache 2.0 Handler，即代表你使用的是 mod_php；報告者示範了攻擊者可透過這個途徑，在應用程式程式碼執行前發動攻擊 [1]

最理想的做法是更新整個系統，然後重新啟動 Apache 或 PHP-FPM，讓 worker 載入新程式碼，因為單是修補檔案並不會令正在執行的程序更新

協調披露的教訓

讀完這份公告後，我想起一個人們經常爭論的問題：embargo 是禮節問題，還是安全問題？

這個案例的答案是兩者皆是，而且有多個難以控制的脆弱環節

• 漏洞通報團隊造成的洩漏 並非來自黑客，而是熟悉詳細情況的團隊不慎自行洩露證據
• 供應商造成的洩漏 源於回應自身客戶的需求，速度快於共同協議
• 社交媒體造成的洩漏 則是因為有人掌握的資訊不完整，於是自行補上錯誤細節

這三種情況都不是出於惡意，而是源於各方的正常動機

我仍未有答案的問題是：如果 AI 每年都令人們更快發現和驗證漏洞，傳統的 embargo 機制是否仍然足夠？還是我們必須改用一種接受資訊總會外洩的做法，並設計機制令洩漏時造成的損害減至最低？

或許可以更早向供應商發布修補程式，但先發布簡短公告，讓用戶提高警覺，並預備好更新渠道

又或者不再把已修補的二進制檔案視為機密，因為它始終可以被比對

我仍未見有人清楚回答這個問題，而我認為這是未來幾年的重大課題

參考資料

[1] The PHP Foundation（2026年10月21日）· 今日發布的 PHP 安全更新，以及我們如何加強 PHP 安全性。 https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
[2] NVD（2026年10月21日）· CVE-2026-109618 CVSS 4.0 基礎分數 9.2，嚴重。 https://nvd.nist.gov/vuln/detail/CVE-2026-109618
[3] Wiz Research（2026年10月21日）· PHP2Shell：AI 揭示影響 70% 互聯網的嚴重遠端程式碼執行（RCE）漏洞。 https://www.wiz.io/blog/php2shell-php-rce
[4] php.net（2026年10月21日）· 安全公告：存在嚴重遠端程式碼執行漏洞，請立即更新（PHP 8.5.12, 8.4.27, 8.3.36, 8.2.35）。 https://www.php.net/archive/2026.php#2026-10-21-5
[5] GitHub 安全公告（2026年10月21日）· GHSA-w8hw-w9fx-j79w（透過 OOM 損毀導致 RCE）。 https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
[6] GitHub 安全公告（2026年10月21日）· GHSA-6wmf-4rv5-p3rp（透過過時的全域狀態導致 RCE）。 https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
[7] NVD（2026年10月21日）· CVE-2026-109619 CVSS 4.0 基礎分數 9.2，嚴重。 https://nvd.nist.gov/vuln/detail/CVE-2026-109619