PHP 基金會認錯：高危漏洞 2024 年就有徵兆，為何修補卡關兩年？

PHP 昨晚修補的關鍵漏洞令全球大亂，結果基金會幾個小時前的事後說明文章中，承認該漏洞 2024 年就被基金會開發者看到，卻因找不到攻擊路徑、修法難取捨而拖了近兩年。直到 Calif 與 OpenAI 回報才全力修補。
（前情提要：OpenAI GPT‑5.6 Sol 揪出 PHP 重大漏洞！影響約七成網站、砸 10 億美元補貼防守端）
（背景補充：美銀用 Mythos 抓出漏洞，找了 1000 個外包工程師趕工修bug）

本文目錄

過去 12 個小時令全球網站如臨大敵的 PHP 高危險漏洞，其實早在 2024 年就發現這個漏洞？PHP 基金會稍早在事後說明文章中坦承，當時找不到具體攻擊路徑，幾套修法又各有代價，團隊靠共識決遲遲拍不了板，修補一再停擺、重來，直言「這次延誤是結構性失敗」，原因出在安全團隊的決策流程與資源不足。

不過有個細節是：文章寫 2024 年僅有理論上的利用可能，團隊「沒有找到具體攻擊路徑」，與明知道能遠端執行程式碼卻放著不修是兩回事。

基金會表示，徵兆是核心開發者在修 Quarkslab 稽核回報的另一個問題時發現的，並非稽核報告中的條目。資安公司 Calif 也這樣描述：當時沒證實可利用，所以沒修。2025 年 4 月公布稽核結果時，基金會寫的是「PHP 開發團隊已處理所有發現的問題」；這個記憶體問題不在稽核條目內，當時也沒有對外說明。

為什麼這麼難修？

PHP 設有 memory_limit（單一請求可用的記憶體上限）。請求若在剛好錯誤的時刻撞上上限，也就是 OOM（記憶體耗盡），PHP 會留下初始化到一半的內部資料，之後又當成有效資料使用，造成記憶體毀損。

難處在位置：記憶體管理與錯誤處理，幾乎每個請求都會經過。基金會說，各套修法要麼破壞向下相容，要麼帶來新的阻斷服務（DoS，讓服務癱瘓的攻擊）風險，要麼逼大量第三方擴充套件跟著改。

最後的修補，依 GitHub 安全公告，是把原本碰到記憶體不足就直接中止請求的機制拿掉，改成在下一個安全點停下，等於改寫 PHP 處理記憶體耗盡的方式。懂引擎深處的核心開發者又少、身兼多職，修補才反覆停擺。

是什麼讓它變成第一優先？

轉折在 2026 年夏天。基金會把 PHP 拉進 OpenAI 的 Patch the Planet 計畫，Calif 7 月 30 日開始稽核。8 月 11 日，Calif 研究員 Ryan Austin 回報一個不需特殊條件就能遠端執行程式碼的漏洞，根因與 2024 年的記憶體問題相同；OpenAI 同一天也獨立回報同一根因。Wiz 在 8 月 24 日、OpenAI 在 9 月 18 日再補上攻擊路徑，影響全貌才清楚。從此修補成為基金會資安人力的第一優先，多人全職投入，兩個多月後發布。

Calif 的說明列出 11 款可在未登入下被打穿的應用，包括 WordPress、Drupal 與 Joomla，並指出最早受影響的程式路徑可追溯到 2012 年發布的 PHP 5.4.0。

Austin 寫道，他沒用特殊框架，也沒用一般人拿不到的模型，靠的是熟悉目標的漏洞歷史，再引導 AI 往那個方向找，因為「LLM 預設會從最新、最顯眼的漏洞往附近的舊程式碼找，不太會主動從冷門的 20 年前利用手法開始」。

PHP 之後怎麼改，網站管理者現在該做什麼？

基金會已開始讓決策可以多數決，並鼓勵折衷；往後修法卡在艱難取捨的嚴重漏洞，會更早送到領導層協助推進。5 月成立了生態系資安團隊，並有新人加入。7 月 1 日以來，團隊發布 15 個 CVE，另處理 106 份無效、重複或無法重現的回報。基金會也呼籲企業、雲端業者與政府出資，因為 PHP 撐起政府服務、網店與銀行，資安工作卻仍靠少數出資聘請的開發者和一點志工。

網站管理者的答案很直接：升級到 8.5.12、8.4.27、8.3.36 或 8.2.35。所有處理網頁請求的 PHP 都在範圍內，包括 PHP-FPM、mod_php、FrankenPHP 與 LiteSpeed。PHP 8.1 以下官方已不再更新，安全團隊另為 7.4、8.0、8.1 提供最小化的原始碼修補，給自行編譯的人使用。暫時緩解有取消記憶體上限的 memory_limit=-1、調低 post_max_size 等，但官方強調都不完整，僅有升級才是完整解方。