PHP 緊急修補兩項遠端執行漏洞：OpenAI 與 Wiz 如何找到問題，網站該確認什麼？
PHP 緊急修補發布 8.5.12、8.4.27、8.3.36 與 8.2.35。本文依維護者公告解釋 AI 研究者分工、執行中版本驗證、容器與代管更新責任，以及舊版最小原始碼回補的界線。
網站的外掛和主題都更新了，仍不代表底下負責執行它們的 PHP 引擎已經修好。
PHP 緊急修補在 2026 年 10 月 21 日公布，四個安全版本修正兩項可能讓未登入攻擊者遠端執行程式的重大漏洞。
OpenAI 同日說明，Calif 使用 GPT-5.6 Sol 找到一項問題，Wiz 也獨立發現兩項漏洞，修補與版本發布則由 PHP 維護者主導。
這不只影響寫 PHP 的工程師。使用代管網站，或把包含 PHP 的容器放上雲端，也得確認真正跑在服務上的版本是否已更新。
AI 找到漏洞，不代表網路上的網站會自動修好。套件供應商、主機商和網站營運者，各有一段需要完成的更新工作。
我的建議是，先確認誰負責底層執行環境，再核對已套用修正的服務。暫時防護只能爭取時間，不能代替維護者要求的更新。
要看懂這次為何需要跨公司協調，先把漏洞所在的位置說清楚。
PHP 緊急修補了什麼？漏洞在網站底層執行環境
兩項問題都位於 PHP 核心處理請求的流程，並非只出在某個網站外掛。
PHP 是網站伺服器上執行應用程式的語言。使用者打開頁面或送出表單，伺服器可能先透過 PHP 處理資料，再回傳畫面，所以網站自己寫的程式之外，還有一層共同依賴。
依 維護者的正式公告，所有提供網站請求的執行環境都應注意，包括 PHP-FPM、Apache 的 mod_php、php-cgi、FrankenPHP 與 LiteSpeed。
這些名稱代表語言引擎和網站伺服器連接的不同方式，一般網站管理者不必逐一學會部署，但需要向供應商確認自己使用哪一種，才能對上更新說明。
官方把 mod_php 的風險列為最高，並表示已有展示案例，可在網站應用程式執行前由未登入請求觸發。這也是單改網站程式或升級外掛，無法直接消除核心漏洞的原因。
遠端執行程式通常簡稱 RCE，意思是攻擊者可能從遠端讓伺服器執行原本不應執行的程式。它比單純頁面顯示錯誤嚴重，因為受影響的是執行環境的信任邊界。
這次兩項漏洞各有 CVE 編號，也就是公開追蹤漏洞的識別碼。第一項 CVE-2026-109618 與記憶體不足時的清理流程有關，尚未完整初始化的內部資料可能被當成有效資料處理。
第二項 CVE-2026-109619 則涉及已失去有效記憶體的舊狀態，後續請求可能在正常初始化之前再次使用它。官方預告將兩者都評為 CVSS v4.0 的 9.2，不能沿用社群不同口徑的滿分說法。
這些是理解影響所需的原因，不代表每個網站已被入侵，也不能從一個嚴重程度分數推算實際受害數量。
相同引擎被許多服務使用，才需要研究者、維護者與供應商提前準備，讓修正能送到不同部署環境。
OpenAI 與 Wiz 各做了什麼？維護者主導的 AI 漏洞案例
模型協助研究，維護者負責修正與發布，不能把不同角色合成一家公司自動完成修補。
在 OpenAI 的協調揭露說明中，Calif 透過 Patch the Planet 計畫使用 GPT-5.6 Sol 發現一項重大漏洞，Wiz 則獨立找到並回報兩項問題。
OpenAI 表示，過去兩個月與維護者、研究者及安全供應商合作，支援技術研究、測試修補和準備防護。語言維護團隊仍主導正式修正與版本發布。
Google Cloud 的應變文章另說明，Wiz 使用多種模型，Gemini 4 Argon 參與發現、補丁驗證與偵測等工作。因此，這起事件也不宜寫成某一模型單獨擊敗所有人工研究者。
對一般讀者，較重要的變化是模型開始參與複雜底層程式的查核，研究成果卻仍要經過維護者確認、不同版本測試和產品供應商部署，才會變成實際保護。
補丁是一組修正程式的變更。如果它只在最新分支有效，仍不足以讓使用舊版套件的網站立即更新，供應商可能需要把修正移植到自己的版本。
這就是為何協調揭露不只是約好一起發新聞。維護者要讓重要參與者有時間準備，也要考慮資訊過早外流後，攻擊者可能更快推導出利用方式。
OpenAI 這次公布的應變架構仍是提案，涵蓋確認與修正、提前通知、政府協調、下游更新，以及公開後支援部署。誰應事前知道哪些資訊，依其說明仍由維護者決定。
官方對「模型先於攻擊者找到」也使用了知悉範圍的限定，不能拿來保證公開之前絕對沒有攻擊。漏洞被找到和實際受害調查，是不同證據。
研究完成後，網站營運者最直接的問題，仍是自己的 PHP 應該拿哪一個修正版。
延伸閱讀：Cloudflare security-audit skill 是什麼？六階段開源資安稽核與沙盒前提
哪些 PHP 版本已修？上游版本、LTS 與舊版回補
官方發布四個安全版本，分別對應仍在支援範圍內的分支，使用者應依自己的來源取得已含修正的更新。
以下是 10 月 22 日查詢官方公告時列出的版本，不代表看到這些數字以下就只能自行猜測是否安全。
| 原本使用的分支 | 官方安全版本 |
|---|---|
| PHP 8.5 | 8.5.12 |
| PHP 8.4 | 8.4.27 |
| PHP 8.3 | 8.3.36 |
| PHP 8.2 | 8.2.35 |
若 PHP 由 Linux 發行版或長期支援供應商提供，套件可能保留自己的版本編號，同時把安全修正移植進去。這種回補稱為 backport，不能只拿上游字串比大小就判定有沒有修。
因此，使用發行版套件的人應查看該供應商對這兩個 CVE 的安全公告和修正套件版本。沒有找到公告時，仍需問供應商，不能自行把版本差異解讀成已安全。
PHP 8.1 與更早分支已不再接受一般上游更新，但「不再一般支援」也不等於完全沒有任何修補路徑。
維護者最新公告特別說明，已為 7.4、8.0、8.1 提供最小原始碼回補，協助自行編譯或無法取得長期支援方案的使用者。這是緊急協助，不能當成舊分支重新恢復完整支援。
自行套用原始碼修正，還有建置、測試與維護責任，所以一般網站用戶不應只看到有檔案就自行拼裝。較實際的順序，是先找主機商或發行版的已修套件，並規劃移到受支援版本。
另外，PHP 8.2 也將在 2026 年 12 月 31 日結束生命週期。這次先取得緊急修正和後續升級規劃可以分開安排，但不應因為剛修好一個漏洞，就以為該分支還有長期支援。
找到修正套件後，還要讓真正提供網站的執行程序載入它，這是更新是否落地的關鍵。
網站、容器與代管服務，怎麼確認更新落地？
要核對的是處理網站請求的執行環境，不能只看管理頁顯示的版本，或終端機裡另一套 PHP。
同一台主機可能有多個 PHP 安裝，命令列工具和網站程序也可能指向不同版本。因此，工程師在終端看到已修版本，只能證明那個工具的來源，不能單憑這一項就結案。
使用代管網站的人，可以請供應商確認服務採用的執行版本、修正公告和生效時間。這比只問「外掛是否更新」更能對準本次核心引擎問題。
如果應用包在容器裡，容器映像就是把程式和依賴一起打包的部署版本。主機上的語言引擎已更新，不代表舊映像中的 PHP 也跟著改變。
所以自建映像的團隊，需要把已修依賴放進新映像、重新部署，再確認服務已切換。只重建檔案而沒有部署，或只重新啟動舊映像，都沒有完成同一件事。
還要確認是否仍有舊程序承接流量。更新完成的證據應對到實際服務，而不是只對到下載成功、套件安裝成功或建置工作顯示通過。
若公司同時有測試站、正式站和背景工作主機，也不能用其中一台的結果代表全部。可以把供應商修正版本對到各自部署紀錄，標出哪些服務已切換、哪些仍待處理，這比只在總工單寫一句更新完成更容易核對。
這些是部署驗證的工作邏輯，並非本站已對任何使用者網站做檢查。不同網站的管理方式不同，應使用原本授權的維運管道，不需要公開建立可讓外人查版本的測試頁。
若網站不能立刻升級，也應把責任和時間說清楚。例如供應商正在準備套件、工程團隊仍需測試相容性，都是具體阻礙，不能只以「有 WAF」當作更新已完成。
不同雲端服務對更新負責的範圍不一樣，Google Cloud 的應變說明提供了可直接比較的例子。
Google Cloud 更新責任怎麼分？自動基底更新與自建映像
標準代管執行環境與自己打包的容器，不會走相同更新路徑，所以不能把「雲端會修」當成通則。
依 Google Cloud 官方應變文章，Google Cloud 本身不受這兩項問題影響，但客戶在其上執行的 PHP 應用仍可能受影響。
App Engine 標準環境中，受支援的 PHP 8.2 以上執行環境會自動更新。較早版本仍須升級到受支援分支，不能因為服務由 Google 提供就繼續使用已停止支援的版本。
App Engine 彈性環境則需要重新部署。若使用自訂執行環境，還要先把依賴更新到已修版本，再重新部署應用。
Cloud Run 和相關函式服務，則要看是否開啟自動基底映像更新。基底映像提供應用所需的作業環境，這一層有自動更新，和自建完整映像的責任不同。
若沒有啟用該機制，或本來就是自己的容器映像，官方要求重建與重新部署。GKE 上的工作負載，也應更新映像並重新部署相應程序。
表面上都叫「放在 Google Cloud」，責任卻可能從供應商自動處理，一路到團隊必須自行更新全部映像。核對產品名稱和部署方式，才能知道誰還有工作沒做完。
Google 文章對舊版本的說明，與上游最新公告新增最小原始碼回補的範圍並不完全一致。對上游修補現況，應以上游維護者最新公告為準，雲端工作負載則再依平台公告確認。
這種差異也提醒營運者，應保留查詢日期和實際採用的供應商公告，避免把較早一份說明當成永遠不變的支援清單。
為何 WAF 與暫時設定不能代替更新？
維護者明確表示，只有更新是完整解法，暫時措施只能降低特定攻擊路徑的暴露，不能讓整個安裝變安全。
WAF 是網站應用程式防火牆，通常在請求抵達應用之前攔截可疑流量。它可以替更新爭取時間，但沒有把引擎裡的錯誤程式碼改掉。
官方也列出若干請求大小、工作程序和特定功能的緩解方法，但同時說明各自只擋住部分路徑。這些設定還可能影響可用性與應用行為，不宜截取一行就當成所有網站的通用解方。
如果需要暫時措施，應由原維運團隊依官方公告、實際執行模式與供應商建議安排，並保留更新計畫。這和讓一般讀者自行複製設定、以為問題已解不同。
修補完成也不能證明過去沒有被利用。版本更新處理的是現在的漏洞條件，是否需要調查先前紀錄，則取決於系統暴露、異常跡象與組織的事件處理程序。
對這次 AI 新聞而言，重點正是在最後一段：模型可以幫研究者找到底層問題，但要讓保護到達網站，還需要維護者發布、供應商適配，以及營運者部署。
能把這幾段責任接起來，才算把研究成果變成實際防護。只記住某個模型找到大漏洞，反而容易忽略使用者現在最需要完成的更新。
延伸閱讀：Codex Security Cloud 完整解析：Daybreak Blue、全程式庫掃描與 AI 修復怎麼用？
PHP 緊急修補常見問題
這次 PHP 緊急修補要更新哪個版本？
官方列出 8.5.12、8.4.27、8.3.36、8.2.35。若使用 Linux 發行版或長期支援套件，應核對供應商針對兩項 CVE 發布的修正版本。
更新 WordPress 外掛就足夠嗎？
不足以直接修正 PHP 核心引擎。需要確認網站服務實際使用的 PHP 已取得修正，外掛更新和執行環境更新是不同工作。
PHP 8.1 和更舊版本完全沒有修補嗎？
不能一概這樣說。一般上游支援已結束，但部分供應商有回補，PHP 最新公告也提供 7.4、8.0、8.1 的最小原始碼回補，仍需確認維護與部署責任。
OpenAI 是獨自找到並修完兩項漏洞嗎？
不是。OpenAI 說明 Calif 使用其模型發現一項重大問題，Wiz 獨立發現兩項，而修正與發布由 PHP 維護者主導，多方參與研究與協調。
先確認已修版本正在服務，再把這次更新結案
這起事件呈現 AI 參與底層資安研究的能力，也呈現修補仍需要跨組織合作。對網站營運者，最有用的下一步是確認供應商已提供修正，而且真正承接流量的版本已更新。
若仍在等更新，應把暫時措施與正式修補分開記錄，不要讓一條防護規則取代最後的部署驗證。
想持續追蹤 AI 資安研究、開發工具與維護者公告，可免費訂閱 AI 郵報，並在執行更新前重新核對最新官方說明。
