跳到正文
Hacker News 熱門(buzzing.cc 中文翻譯)·· 2 小時前精選AI 評分76

PHP 專案發佈 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35,並説明安全工作改革

今天的 PHP 安全更新,以及我们如何加强 PHP 安全性

AI 導讀

PHP 專案發佈 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35,修補兩個可在特定條件下讓未經認證的攻擊者於伺服器執行程式碼的嚴重漏洞。兩個漏洞分別涉及記憶體管理與錯誤處理;文章回顧 2024 年外部審計後的安全工作,並介紹新設的 Ecosystem Security Team、增聘人手及驗證工具。

推薦理由

文章交代兩個遠端程式碼執行漏洞的根源、修補延誤及團隊改革,呈現 PHP 安全維護中的技術取捨與人手需求。

正文 · 繁體中文

今日較早時,PHP 專案發布了 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。這些版本修正了兩個嚴重漏洞,在特定條件下,未經驗證的攻擊者可利用漏洞在執行 PHP 的伺服器上執行程式碼。如果你使用 PHP,務必立即更新。php.net 上的公告載有並引述了漏洞、攻擊途徑的技術詳情,以及如何在不同系統上更新的指示。

這篇文章並非講解如何更新,而是探討這些漏洞如何被發現和修正、過去兩年 PHP 的安全處理方式有何改變,以及我們需要依賴 PHP 的機構做些甚麼,才能讓 PHP 的安全工作持續下去。

  • CVE-2026-109618 / GHSA-w8hw-w9fx-j79w:透過 OOM 損毀執行遠端程式碼(記憶體不足):如果請求在錯誤的時機觸及 PHP 的 memory_limit,PHP 可能會留下只完成部分初始化的內部資料,之後再將其視為有效資料,導致記憶體損毀。在使用 mod_php 的 Apache 上,未經驗證的請求可在任何應用程式程式碼執行前觸發此問題;研究人員已證明,在預設設定下可完整執行遠端程式碼。研究人員亦確認,可透過應用程式層級的程式碼路徑,在 PHP-FPM 上執行遠端程式碼。
  • CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp:透過過時狀態執行遠端程式碼:在錯誤的時機發生致命錯誤,可能會令內部狀態仍指向屬於先前請求的記憶體。之後由同一個工作進程處理的請求,便可能使用這段已釋放的記憶體。研究人員確認了釋放後使用問題及工作進程崩潰;報告者亦展示瞭如何針對一個使用 mod_php、在 Apache 上執行的真實應用程式執行遠端程式碼。

這兩個問題都出現在 PHP 幾乎每個請求都會涉及的部分:記憶體管理和錯誤處理。它們在 PHP 中的核心地位,令這兩個漏洞格外嚴重,也令修正工作格外困難,因為修正可能會破壞相容性、降低效能,或迫使龐大的第三方擴充功能生態系統作出改動。

首次外部審核及加強安全工作

2024 年,PHP 多年來首次接受外部安全審核。PHP Foundation 獲 Sovereign Tech Agency 提供資金,透過 OSTIF 籌辦這次審核,並由 Quarkslab 執行。PHP Foundation 聘用的一名 PHP 核心開發人員在修正 Quarkslab 報告的其中一個問題時,發現了導致 CVE-2026-109618 的 OOM 問題初步跡象。2024 年時,有人推測 OOM 問題可能存在可利用方式,但未找到具體攻擊途徑,而其他影響明確的具體問題亦令這些疑慮未受重視。

為修復 OOM 問題,PHP 安全團隊制定了幾種互相競爭的方案,但各有取捨:破壞向後兼容性、帶來新的拒絕服務攻擊風險,或要求大量第三方擴充套件作出更改,而這些更改似乎難以協調。以共識為決策原則的 PHP 安全團隊難以在這些方案中作出選擇,並擔心採用錯誤方案所帶來的後果。再加上當時尚未發現可導致遠端程式碼執行的途徑,而具備引擎深厚知識的核心開發人員人數不多,且身負多項職責,這個決策流程令修復工作在數月間屢次停滯又重新開始。我們不會掩飾:這次延誤是結構性失誤,既由安全團隊的決策流程造成,也源於資源不足。此後,安全團隊已開始改變其工作流程,並會繼續推進,讓決策改以多數決作出,並鼓勵各方妥協。

建立可持續發展的專業安全組織

過去幾個月,PHP 安全工作的組織方式已有很大改變。2026年5月,PHP Foundation 成立了 Ecosystem Security Team,與 PHP 安全團隊合作處理分流、協調及安全強化工作。Volker Dusch 在 PHP Foundation 擔任駐任 AI 安全工程師期間的工作,大幅改善了 PHP 安全團隊與 PHP Foundation 之間的溝通和合作。Alexandre Daubois 加入 PHP Foundation,於7月協助 PHP 安全團隊為安全報告進行分流、處理及修復工作;Daniel Scherzer 加入團隊,於9月負責安全強化工作。

今年較早時,我們與 Alpha-Omega 合作,使用 Anthropic 的 Claude Mythos 掃描 PHP。自 Mythos 掃描後,我們又加入其他工具,包括 OpenAI 的 Daybreak Red,用來驗證報告和漏洞利用程式;此外亦加入 sanitizer 建置版本,以及在 PHP 支援的每個平台上與我們的 CI 相符的重現環境。

PHP Foundation 讓 PHP 專案加入 Patch the Planet 計劃。作為計劃的一部分,安全公司 Calif 於2026年7月30日開始審核 PHP。8月11日,Calif 研究員 Ryan A 報告了一個無條件遠端程式碼執行漏洞,其根本原因與我們在 2024 年發現的 OOM 問題相同。OpenAI 亦在同日獨立報告了相同的根本原因;其後,OpenAI 於9月18日、Wiz 於8月24日分別報告了更多攻擊途徑。最近,Trail of Bits 亦開始審核 PHP。來自 Calif、OpenAI 及 Wiz 的報告清楚揭示了 OOM 問題的全部影響;自8月11日起,修復這個問題成為 PHP Foundation 所有從事安全工作的團隊成員的首要任務。若沒有 PHP Foundation 的資助,多名人員便不可能全職處理這個問題,後來甚至在週末及全天候投入工作,以便與其他相關方協調及溝通。

AI 輔助研究日益普及,也意味着 PHP 安全團隊收到的報告遠比以往多。正如 Alexandre Daubois 上星期在PHP 安全團隊如何處理你的報告一文中所述,團隊自 7 月 1 日起已發布 15 個 CVE,並處理了 100 多宗報告,結果發現它們無效、重複或無法重現。AI 有助團隊驗證報告,以及把根本原因相同的報告歸類,但每項判斷均由人員作出,每個修補程式也由人員處理。

洩漏及披露安排受阻

這些漏洞的協調披露原本進展順利,直至預定發布日期前 2 天。

10 月 20 日星期二約 15:00 UTC,兩個 CVE 編號開始在網上論壇及社交媒體流傳。相關消息附有錯誤的發布時間,以及錯誤的 CVSS 分數 10.0(實際分數為 9.2)。沒有技術細節外洩。作為回應,PHP 專案提前發布預告,並於19:30 UTC 發布。專案亦把發布時間由 10 月 22 日 14:00 UTC 提前至 10 月 21 日 14:00 UTC。發行版仍在打包修補程式,因此若立即發布,許多用戶便無法輕易更新。把發布時間提前一天,是在迅速採取行動、給予各方準備時間,以及確保漏洞披露時所有人都能簡單更新之間,最理想的折衷方案。

由於洩漏及約於 20:00 UTC 發布預告,曾報告問題的安全公司之一 Calif 誤發了一段影片。影片展示其概念驗證如何攻擊多個目標,並透露了少量額外的漏洞細節。影片刪除後不久,副本便開始在社交媒體流傳。這段影片促使各種 PoC(漏洞利用概念驗證)的開發加快,並進一步令相關內容於 10 月 21 日加速流傳。

我們於 10 月 20 日約 23:00 UTC 開始向幾間關鍵基礎設施供應商提供緩解措施建議,這些建議亦可能已經外洩。洩漏發生後,PHP 安全團隊密切監察及檢查陸續出現的 PoC,但在發布/公開披露時並未發現任何可運作的漏洞利用程式。

10 月 21 日 07:41 UTC,距離協調發布尚有超過六小時,Chainguard 單方面打破保密期限,發布了包含修補程式的已建置映像檔。與其他發行商一樣,Chainguard 提前收到修補程式,讓其用戶能在漏洞披露時立即更新。此時,任何攻擊者都可以研究二進制形式的修補程式,而其他 PHP 用戶仍在等待發布。這無視了多方為協調披露付出數星期的努力。

審慎樂觀的展望

今日發布的內容展現了我們在處理 PHP 安全問題方面取得的進展。8 月確認 OOM 問題的全部影響後,安全團隊、基金會及發布管理員為所有受支援分支中這個根深蒂固的問題提供了修補程式;各發行版及 LTS 供應商也提前收到修補程式,讓用戶可以迅速更新。

我們有信心,日後若遇到修補方案受制於艱難取捨的嚴重漏洞,相關情況會更快傳達至 PHP Foundation 領導層;我們正在調整流程,讓領導層能協助推動問題及時解決。我們現正優先採取措施,確保日後收到需要同樣複雜修補方案的漏洞報告時,能更快處理。過去數星期,PHP Foundation 和 PHP 安全團隊學到了很多,並會致力把這些經驗轉化為持久、可重複執行的流程。

我們需要你們提供的協助

PHP 支撐網絡上很大一部分服務,包括政府服務、網上商店、銀行、媒體網站,以及企業日常依賴的許多軟件。然而,PHP 本身的安全工作仍依賴一小羣由基金會資助的開發人員,以及少量義工協助。

如今,無論防守方還是攻擊方,工具尋找程式錯誤的速度都前所未有,而漏洞報告的數量亦會持續增加。但工具無法為引擎中沿用已久的設計決策選出合適的修補方案、權衡相容性取捨並審查修補程式。作出這些決定,需要熟悉整個 PHP 程式碼庫的資深工程師,而目前這類工程師人數不足。

PHP Foundation 的核心使命之一,是增加深入掌握 PHP 程式碼庫的工程師人數,並為安全團隊提供所需資源。要實現這個目標,唯有依靠使用 PHP 的各方提供資金:

  • 以 PHP 建構產品和服務的公司:請按照貴公司對 PHP 的依賴程度,向 PHP Foundation 提供相應級別的贊助。
  • 為數以百萬計用戶提供 PHP 的主機服務供應商、雲端平台及發行版。
  • 服務以 PHP 運作的政府和公共機構。德國 Sovereign Tech Agency 為 2024 年審計提供資金,展示了公共投資能帶來甚麼成果;我們需要更多這類資助,並且持續投入。

贊助 PHP Foundation,是確保 OOM 漏洞等結構性問題在演變成緊急事故之前獲得可持續處理的最直接方法。請前往 thephp.foundation/sponsor 成為贊助者;如果貴機構希望商討更大額的承諾,請聯絡我們。

感謝

感謝 PHP 安全團隊、義工和 PHP Foundation 的合約人員、發行管理員,以及各發行版和 LTS 供應商的套件維護人員,感謝他們促成這些版本推出。感謝 Calif(尤其是 Ryan A)、Wiz、OpenAI Codex Security(尤其是 Amy Burnett)、OSTIF 及 Quarkslab 所作的研究和負責任披露;感謝 Alpha-Omega、OpenAI 及 Anthropic 讓團隊使用其工具,並資助部分安全工作;感謝 Sovereign Tech Agency 資助 2024 年審計;亦感謝所有贊助者,你們的支持讓這項工作得以完成。

來源:Hacker News 熱門(buzzing.cc 中文翻譯) · thephp.foundation