昨天 PHP 基金會發了一篇長文，講這次兩個重大漏洞怎麼被找到、怎麼修掉，以及過去兩年 PHP 安全處理方式的改變。我把全文翻成中文，後面再整理 Hacker News 上 331 則留言的反應。一頁看完的懶人包放在文末。
先講結論
PHP 8.5.12、8.4.27、8.3.36、8.2.35 修掉兩個 CVSS 9.2 的漏洞，未經驗證就能遠端執行程式碼。有跑 PHP 就現在更新。公告在 php.net，技術細節、攻擊向量與各系統更新方式都在那裡。
基金會原文翻譯
今天稍早，PHP 專案釋出了 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。這些版本修掉了兩個重大漏洞，在特定條件下，未經驗證的攻擊者就能在伺服器上執行程式碼。如果你有跑 PHP，務必現在就更新。
這篇文章不講怎麼更新。而是講這些漏洞如何被發現與修掉、過去兩年 PHP 安全處理方式有什麼改變，以及我們需要依賴 PHP 的組織提供什麼，才能讓 PHP 安全工作持續下去。
兩個相關的重大遠端程式碼執行漏洞
第一個是 CVE-2026-109618，經由記憶體耗盡污染的 RCE。如果一個請求剛好在最壞時機撞上 memory_limit，PHP 可能留下半初始化的內部資料，之後又把它當成合法資料，進而損毀記憶體。在 Apache 加 mod_php 上，未經驗證的請求在任何應用程式碼執行前就能觸發，已經在預設設定下展示完整遠端程式碼執行。PHP-FPM 也經由應用層路徑確認可攻陷。
第二個是 CVE-2026-109619，經由殘留全域狀態的 RCE。致命錯誤發生在錯誤的時機，內部狀態就會指向前一個請求的記憶體。同一個 worker 接到的下一個請求，可能用到那塊已釋放的記憶體。已經確認 use-after-free 與 worker 崩潰，通報者也在跑 Apache 加 mod_php 的真實應用上展示攻陷。
兩個問題都位在幾乎每個請求都會經過的地方：記憶體管理與錯誤處理。正因為位居核心，才會這麼嚴重，也才會這麼難修。動任何一處都要顧相容性、效能，還有龐大的第三方擴充生態系。
第一次外部稽核與安全重心的轉移
2024 年，PHP 經歷多年來第一次外部安全稽核。基金會向 Sovereign Tech Agency 爭取到經費，經由 OSTIF 辦理，由 Quarkslab 執行。在修 Quarkslab 通報的問題時，一位基金會出錢聘的開發者，發現了第一個漏洞背後 OOM 問題的最初跡象。當時曾經推測過可能被利用，但沒找到具體路徑，又有其他影響明確的問題排在前面，這個疑慮就被蓋過了。
修 OOM 問題有好幾個方案，但每個都有代價。破壞向下相容、帶來新的阻斷服務風險，或要求大量第三方擴充跟著改，看起來根本協調不起來。安全團隊採共識決，遲遲選不出方案，又怕選錯。當時也沒有已知的遠端執行路徑，懂引擎深層細節的人又少又忙，修復工作幾個月內反覆停滯重啟。基金會在文章裡沒有粉飾，直說這是結構性失敗，來自決策流程，也來自資源不足。安全團隊此後改成多數決，這項工作還在繼續。
專業安全組織的建立
過去幾個月變化很大。2026 年 5 月基金會成立生態系安全團隊，跟原本的安全團隊並肩做分類、協調與強化。7 月與 9 月又各有一位工程師加入，分別負責通報處理與強化工作。
工具面，今年稍早跟 Alpha-Omega 合作，用 Anthropic 的 Claude Mythos 掃過一輪。之後又加上 OpenAI 的 Daybreak Red 做通報與利用驗證，外加 sanitizer 建置與全平台重現環境。基金會還讓 PHP 加入 Patch the Planet 計畫，安全公司 Calif 從 7 月 30 日開始稽核，8 月 11 日通報了一個無條件遠端執行，根因跟 2024 年發現的 OOM 問題相同。OpenAI 同一天獨立通報同一根因，Wiz 在 8 月 24 日、OpenAI 在 9 月 18 日又補上更多攻擊路徑。近期 Trail of Bits 也在稽核。這些通報讓 OOM 問題的完整影響明朗化，從 8 月 11 日起，修掉它成為基金會所有安全人力最高優先的事。文章裡寫得很白，沒有基金會出錢，不可能讓多人全職投入，最後甚至週末加班日夜趕工。
AI 輔助研究也讓通報量暴增。團隊自 7 月 1 日以來發了 15 個 CVE，處理了 100 多件最後證實無效、重複或無法重現的通報。AI 幫忙驗證與歸類，但每個判斷、每個修補都是人做的。
洩漏與被打亂的協調揭露
目標發佈日前兩天之前，協調揭露原本順利。10 月 20 日下午約 15:00 UTC，兩個 CVE 編號開始在論壇流傳，附帶錯誤的發佈時間，CVSS 分數也錯寫成 10.0，實際是 9.2。沒有技術細節外洩。PHP 專案提前發出預告，把發佈日從 10 月 22 日提前到 10 月 21 日。當時各發行版還在打包，立刻釋出會讓很多使用者沒有簡單的更新管道，提前一天是折衷。
約 20:00 UTC，通報廠商之一 Calif 誤發一支影片，展示概念驗證在多個目標成功，揭露少量漏洞細節。影片刪除後拷貝在社群瘋傳，加速了各式概念驗證的出現。基金會給少數關鍵基礎設施業者的緩解建議也可能外洩了。安全團隊密切監控出現的概念驗證，到公開時點沒有發現可實際運作的利用。
10 月 21 日 07:41 UTC，協調公開前六個多小時，Chainguard 單方面打破禁發期，釋出含修補的映像檔。跟其他發行商一樣，Chainguard 提前拿到修補是為了讓使用者在揭露當下就能更新。但如此一來，攻擊者就能以二進位形式研究修補，而其他使用者還在等。這漠視了多方數週的協調努力。
謹慎樂觀的前景
基金會說有信心，未來再有卡在艱難取捨的嚴重漏洞，會更快送到高層，用流程改變推進及時解決。過去幾週學到的東西，會轉成可長期重複的流程。
基金會需要什麼
PHP 撐起網路的很大一塊，政府服務、網店、銀行、媒體都在上面。但本體安全工作至今靠少數基金會出資的開發者加少量志願協助。工具找漏洞的速度空前快，防守方與攻擊方都一樣，通報量只會漲。工具做不到的是為引擎長年設計決策選出正確修補、權衡相容性、審查程式碼。這些判斷需要熟悉整個程式碼庫的資深工程師，現在這種人太少。
呼籲對象有三種：在 PHP 上做產品與服務的公司、把 PHP 送到數百萬使用者手上的託管與發行商、服務跑在 PHP 上的政府與公部門。贊助頁在 thephp.foundation/sponsor。
HN 網友反應整理
討論串 669 分、331 則留言，氣氛是一邊救火一邊吵架。
資訊禁發期
資訊禁發期是各方約好在協調揭露完成前不得提前公開的時間。拿到提前修補的發行商，必須等到官方公開當下才能公開，避免攻擊者先從二進位檔反推出漏洞。
多數人譴責 Chainguard，說找不出正當理由，有人主張蓄意破壞禁發期的公司該冷凍 365 天。少數人認為 2026 年了禁發期本來就蠢，早發早減少停機。最好笑的補刀是 Chainguard 自家 Wolfi 機器釋出後幾小時還沒修補，SiteGround 反而一小時內自動幫使用者升級完。上游安全廠商破禁發期，下游主機商更新更快。
洩漏鏈也有人還原。CVE 編號外洩後，Calif 誤發的展示影片刪除又瘋傳，實質幫攻擊者補上最後一塊拼圖。而 CVE 編號最早在 HN 是 @petecooper 貼的，他的消息來源保證沒有禁發期，事後證實是謊言，他在串裡自首道歉。
實戰派拿 HN 當緩解交換所
@ dofm 靠討論串拼出的三行 nginx 規則擋 multipart 上傳，保住一台關不掉的機器，在修補釋出前一小時還在擋。攻擊量不大，數十到數百次，來源涵蓋 Anthropic、OpenAI、Qwen、百度，看起來像雲端 AI 搜尋服務，某個時間點像被統一拔插頭一樣同時停止。手法現成好用，針對常見路徑連續發送 POST，只打看起來像 PHP 應用的網域。自動化攻擊懶得擦紀錄，重點是蠕蟲式打法，打下一台當跳板就走。
緩解措施也吵了一輪。有人不滿大廠早拿修補，官方卻不講擋上傳就能擋掉大部分。有人當場糾正，關上傳不算真正緩解，會給人錯誤安全感。官方溝通也被批，預告寫了洩漏就可能提前公開，結果洩漏後完全沉默。
PHP 辯護與重寫派
辯護派說這不是 PHP 語言爛，是 C 寫法爛，定位是 Heartbleed 等級。換語言也不會自動變安全。重寫派問會不會出現 Rust 重寫的分支，有人潑冷水，Rust 只消滅一類漏洞，大模型加速挖洞的問題還在。務實派抱怨 PHP 向下相容不如 Node，加上安全修正只給近期版本，漏洞等於逼人跟著升級。
一頁懶人包
手機版看不見內嵌頁時，直接開備援連結：https://derek-static.pages.dev/php-rce-lazy.html
來源
PHP 基金會原文、php.net 公告、HN 討論串連結都在懶人包最後一格，這裡不再重貼。