PHP 兩個重大遠端程式碼執行漏洞已修補：修補前假 PoC 與錯誤緩解建議滿天飛
資安研究
2026-11-02 by 高田鑑識
本文整理自 Checkmarx Zero 研究團隊發表的〈PHP2Noise – Two PHP Critical RCEs Patched As Users Scramble for Fix Amid Misinformation〉。原文稱這次事件為「PHP2Noise」：兩個重大 RCE 漏洞在修補程式發佈前，就已引發大量雜訊、假的概念驗證程式碼（PoC）與錯誤的緩解建議。
重點摘要
- 漏洞：CVE-2026-109618 與 CVE-2026-109619，兩者 CVSS 4.0 皆為 9.2，屬於未經驗證即可觸發的遠端程式碼執行（RCE）。
- 時間線：PHP 團隊 10 月 20 日發出預告，10 月 21 日釋出修補版本。
- 影響範圍：PHP 在公開網路上約占 75%，使用 PHP 的框架也同樣受影響。
- 唯一完整的解法：更新到修補版本；坊間流傳的緩解建議，PHP 維護者表示是不實的，無法提供完整保護。
- 需特別留意：PHP 版本屬於作業系統層，一般的 SBOM 與 SCA 掃描偵測不到。
| PHP 版本線 | 請升級至 |
|---|---|
| 8.5.x | 8.5.12 |
| 8.4.x | 8.4.27 |
| 8.3.x | 8.3.36 |
| 8.2.x | 8.2.35 |
| 8.2 以前 | 已終止支援（EOL），不會有修補版本，必須遷移到 8.2 以上 |
事件經過
2026 年 10 月 20 日，PHP 團隊對「所有 PHP 使用者」發出通知，預告即將發佈緊急安全性更新，並承諾 10 月 21 日提供修補與完整揭露。更新要處理的是兩個 CVSS v4.0 評分 9.2 的重大漏洞，並已於 10 月 21 日（週三）釋出。
原文指出，在修補程式發佈前的這段空窗，網路上迅速出現各種號稱的 PoC 與假的緩解建議。在官方更新釋出前，就已有資安社群成員宣稱做出這兩個漏洞的 PoC，但這些程式碼不是殘缺就是無法運作。作者提醒，驗證新漏洞時，要特別小心聲稱是攻擊程式的程式碼，因為它們可能夾帶惡意程式。
PHP 團隊在修補程式發佈前，對所有使用者發出的重大安全性更新預告（圖片來源：Checkmarx Zero）
兩個漏洞的成因
| CVE 編號 | CVSS 4.0 | 成因 | 備註 |
|---|---|---|---|
| CVE-2026-109619 | 9.2 | 部分 PHP 全域變數在請求結束後仍然存活，卻指向該請求已釋放的記憶體；在下一個請求重新初始化之前，這塊記憶體仍可能被某些操作存取，形成釋放後使用（use after free） | 攻擊者需要知道伺服器的堆積（heap）結構 |
| CVE-2026-109618 | 9.2 | 記憶體不足（OOM）錯誤觸發記憶體損毀：記憶體耗盡時，程式以 longjmp() 在無效狀態下離開目前的執行環境，可能導致攻擊者控制的記憶體被執行 | 檔案上傳可穩定觸發：例如不宣告內容長度、注入多個標頭、上傳多個空檔案產生檔案標頭，耗盡記憶體 |
簡單來說，這兩個問題都是記憶體安全問題，攻擊面落在處理請求與檔案上傳的流程上，因此屬於未經驗證即可觸發的漏洞。
哪些版本受影響
所有仍受支援、且低於 8.5.12、8.4.27、8.3.36、8.2.35 的 PHP 版本都有漏洞。8.2 以前的版本已終止支援，原文指出據稱不會有修補版本，這些版本同樣有漏洞，必須遷移。
官方公告提及的部分緩解方式
| 漏洞 | 官方公告提及的部分緩解方式 | 限制 |
|---|---|---|
| 其中一個 RCE | 設定 memory_limit=-1 | 等於取消記憶體限制，可能造成記憶體耗盡，需要進一步調整設定 |
| 另一個 RCE | 設定 fatal_error_backtraces=0 與 session.upload_progress.enabled=0 | 會同時停用這些功能 |
原文強調，唯一完整的緩解方式是更新到修補版本。在等待修補期間，網路上也流傳其他設定建議，例如停用無關的工作階段機制，但自稱參與 PHP 的人士表示「ini 設定救不了你」，也就是即使宣稱的攻擊屬實，也可能有其他方式觸發漏洞，上述設定並非攻擊的先決條件。這些說法後來證實只是部分或不完整的緩解，沒有任何一個能同時涵蓋兩個 CVE，因此等待官方發佈才是穩妥作法。
「預告修補」這個做法還適用嗎？
原文也對「預告即將發佈修補」的做法提出檢討：
- 傳統的好處：預告能讓使用者提前準備好，在修補程式一釋出就立刻部署，而且在預告與修補之間的空窗期裡，攻擊者很難把漏洞逆向成可用的攻擊程式。
- LLM 帶來的變化：大型語言模型（LLM）加入研究與攻擊程式開發流程後，攻擊者可以快速檢索近期更新、git 變更、議題、公開討論，甚至原始碼本身，找出線索，大幅提高攻擊程式的開發速度。這次的預告本身，很可能反而促成了攻擊程式的開發。換句話說，為縮短曝險時間而發出的預告，可能變成自我實現的預言，讓攻擊程式更早出現。
- 另一面的問題：圍繞這份通報，出現大量臆測、錯誤資訊與恐慌（FUD），以及無效、不完整或過度特定的 PoC。這提醒我們：事情看似緊急，仍應等待官方確認、緩解建議與修補。
作者的結論是，就這次事件而言，「預告修補」的做法辜負了使用者，反而助長混亂，也許該是重新檢討這個做法的時候。
如何找出有漏洞的版本
原文特別提醒：PHP 版本屬於作業系統的一部分，而不在軟體物料清單（SBOM）之中，因此軟體組成分析（SCA）這類 SBOM 掃描不會偵測到這個問題。要評估曝險，組織需要自行盤點已安裝的 PHP 版本，並與官方公布的受影響版本比對，方式包括主機弱點掃描、系統套件盤點，或直接檢查版本：
php -v原文另提到，Checkmarx Container Security 可在支援的容器設定中，找出含有相關 CVE 的 PHP 套件。
以下是我補充的幾個常見檢查方式，請依實際環境調整（原文沒有提供）：
# Debian / Ubuntu
dpkg -l | grep -i php
# RHEL / CentOS / Rocky
rpm -qa | grep -i php
# 容器映像檔
docker run --rm <映像檔> php -v另外，多版本 PHP 並存的主機（例如 aaPanel、寶塔等面板環境）請逐一檢查每個版本，而不只是預設的 CLI 版本。
結論
請立即將 PHP 更新到 8.5.12、8.4.27、8.3.36 或 8.2.35。其他被提出的修補建議，不是只有部分效果、帶來新的問題，就是完全無關。
作者認為，這次衝擊 PHP 世界的重大漏洞是未來的預兆：攻擊程式開發的速度，以及錯誤資訊散布的速度，都已超過防守方應對迫在眉睫攻擊的能力。在官方資訊公布之前，對任何已發表的緩解方式與攻擊程式，都應保持懷疑。
參考資料（原文所列）：
- PHP 官方安全公告：GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp（php/php-src）
- PHP 官方發佈公告：php.net 2026-10-21 發佈訊息
高田觀點
對事件調查而言，這類「公開前預告、修補後立即出現攻擊」的漏洞，最需要留意的是修補前的空窗期：升級完成不代表沒有被入侵過。建議升級的同時，回溯檢視 10 月 20 日之後的網站日誌，特別是異常的檔案上傳請求（缺少內容長度、多個空檔案、大量標頭）與伺服器記憶體耗盡的錯誤紀錄，並檢查 PHP 程序是否有非預期的子程序或對外連線。
