>_toolkitbox

~/ / AI 文章 / AI 協助發現 PHP2Shell：2026 年 10 月 PHP 的嚴重漏洞

AI 協助發現 PHP2Shell：2026 年 10 月 PHP 的嚴重漏洞

根據媒體報導，AI 模型協助研究人員在 PHP 本身發現兩個嚴重漏洞 CVE-2026-109618 與 CVE-2026-109619，這兩個漏洞可能讓未經驗證的攻擊者執行遠端程式碼。PHP 已於 2026 年 10 月 21 日發布修正版本。本文整理官方公告與相關報導對這些漏洞以及 AI 參與方式的說明，並讓你檢查自己所用的 PHP 是否已含修正。

已於 2026-10-24 對照官方公告確認。本頁不是官方公告,細節可能會變動,請以頁面底部的來源為準。

首先該做的事

  1. 將 PHP 更新到已修補的版本(8.5.12、8.4.27、8.3.36 或 8.2.35),或更新到 Linux 發行版提供的已修補套件。PHP 表示沒有完整的緩解措施,更新是唯一安全的選擇。
  2. 更新後,請重新啟動 PHP-FPM、Apache 以及所有長時間執行的 PHP worker,讓它們載入修補後的程式碼。在更新之前啟動的服務,執行的仍是舊的程式碼。
  3. 如果 PHP 來自發行版的套件,請確認完整的套件版本,包括第一個連字號之後的部分。發行版可能在不改變版本號碼前半部的情況下納入修補。
  4. 如果無法立即更新,請參閱下方的緩解措施。PHP 表示這些措施能降低特定攻擊路徑的風險,但不能讓安裝變得安全。

發生了什麼事

2026 年 10 月 21 日,PHP 發布了 8.5.12、8.4.27、8.3.36 與 8.2.35。這些版本修補了兩個嚴重漏洞,兩者的 CVSS v4.0 評分皆為 9.2。

CVE-2026-109618,稱為 RCE via OOM corruption:記憶體不足的處理過程可能在內部請求資料只初始化到一半時中斷 PHP,之後請求的清理程序可能把這份無效的資料當成有效資料。

CVE-2026-109619,稱為 RCE via stale global state:屬於請求的內部狀態,在其底層記憶體被釋放之後仍可能殘留,同一個 worker 後續處理的請求可能會使用這份過時的狀態。

  • CVE-2026-109618 · CVSS 4.0 9.2
  • CVE-2026-109619 · CVSS 4.0 9.2

AI 如何參與其中

根據 The Next Web 的報導,資安公司 Calif 在 8 月藉助 OpenAI 的模型發現了第一個錯誤,當時是在由 OpenAI 出資的 PHP 原始碼稽核中。Wiz 表示,他們在數週之後獨立發現了這些缺陷,使用的 AI 工具包括 Google 的 Gemini 模型。

網站 php2shell.com 將這項研究歸功於 Wiz Research、OpenAI Codex Security 與 Calif。Calif 表示他們使用的是一般可取得的模型,而且熟悉 PHP 的歷史比模型本身更重要。

同一篇文章報導,Cloudflare 在揭露前約九小時為其客戶啟用了 WAF 規則,之後有概念驗證的攻擊程式在網路上流傳。php2shell.com 網站表示,不應將 WAF 或 CDN 規則視為更新 PHP 的替代方案。

時間軸

  1. PHP 宣布即將發布嚴重的安全性版本,預定於 10 月 21 日 14:00 UTC 發布。
  2. PHP 8.5.12、8.4.27、8.3.36 與 8.2.35 連同安全公告一併發布,Ubuntu 發布 USN-8948-1。
  3. PHP 發布關於 session.upload_progress.enabled 的資訊性公告,針對另一個可能性不高、追蹤編號為 CVE-2026-115560 的攻擊途徑。

哪些系統受到影響

PHP 表示,所有處理網頁請求的 PHP 安裝都有風險,包括 PHP-FPM、搭配 mod_php 的 Apache、php-cgi、FrankenPHP 與 LiteSpeed。PHP 認為 mod_php 的風險最高,因為未經驗證的請求可以在任何應用程式碼執行之前就觸發攻擊。

GitHub 公告將低於 8.2.35、8.3.36、8.4.27 與 8.5.12 的版本列為受影響版本。網站 php2shell.com(顯示為由 Wiz 營運)表示,受影響的版本可追溯到 PHP 5.4。

PHP 8.1 與更舊的版本已不再由 PHP 專案提供更新。部分發行版與 LTS 供應商提供向後移植的修補,而 PHP 為從原始碼自行建置的使用者,提供了 PHP 7.4、8.0 與 8.1 的最小幅度原始碼向後移植。

已修補的版本

等於或高於所屬分支修補版本的版本,即已含修補。發行版的套件是以套件版本判斷是否已修補,因此 Ubuntu 與 Debian 請參考第二個表格。

PHP 官方發行版本

分支首個修補版本
PHP 8.58.5.12
PHP 8.48.4.27
PHP 8.38.3.36
PHP 8.28.2.35

Ubuntu 與 Debian 套件

發行版套件已修補的套件版本公告
Ubuntu 26.10php8.58.5.9-0ubuntu2.1USN-8948-1
Ubuntu 26.04 LTSphp8.58.5.4-0ubuntu1.5USN-8948-1
Ubuntu 24.04 LTSphp8.38.3.6-0ubuntu0.24.04.13USN-8948-1
Ubuntu 22.04 LTSphp8.18.1.2-1ubuntu2.28USN-8948-1
Debian 12 (bookworm)php8.28.2.35-1~deb12u1DLA-4848-1
Debian 13 (trixie)php8.48.4.27-1~deb13u1DSA-6574-1

表格只列出官方公告所載的內容。其他發行版請查看供應商的安全公告。

檢查你的 PHP

選擇你的 PHP 來自何處,貼上版本文字,工具就會與上方已修補的版本比對。它只會判斷你貼上的文字,看不到實際執行的是哪個版本,因此也請確認服務在更新後已重新啟動。

可顯示版本的指令

  • php -v
  • dpkg -l 'php*' | grep ^ii
  • apt-cache policy php8.3-fpm | grep Installed

所有處理都在你的瀏覽器中執行。你貼上的文字不會被上傳。

如果無法立即更新

以下是 PHP 列出的措施。PHP 表示這些措施能降低特定攻擊路徑的風險,但不能讓安裝變得安全,只有更新才是完整的解決方式。

CVE-2026-109618

  • 設定 memory_limit=-1,最好以應用程式無法覆寫的方式設定,例如在 FPM pool 或 Apache 設定中使用 php_admin_value。底層的記憶體配置失敗仍可能走到有漏洞的路徑。
  • 將 post_max_size 設得較低:不需要檔案上傳的應用程式設為 8M,需要上傳時設為 32M。讓 upload_max_filesize 小於 post_max_size。
  • 在網頁伺服器或代理伺服器上,對解碼後的請求大小、輸入欄位數量、multipart 部分的數量、標頭數量與巢狀深度設下限制。
  • 使用容器或 cgroup 的限制作為可用性的界線。不要使用 RLIMIT_AS 或 RLIMIT_DATA,因為它們可能造成有漏洞的記憶體配置失敗。

CVE-2026-109619

  • 在 php.ini、FPM pool 或伺服器設定中設定 session.upload_progress.enabled=0,並重新啟動所有 worker。不要依賴 ini_set() 或 FPM 的 .user.ini 檔案。
  • 在 PHP 8.5 上,設定 fatal_error_backtraces=0,並重新啟動所有 worker。
  • 移除在初始化之前就會輸出診斷訊息、且在每次請求時套用的無效或已棄用設定。隱藏診斷訊息沒有幫助。
  • 修正攻擊者可觸及的嚴重錯誤與執行逾時問題。

10 月 23 日的資訊性公告

PHP 建議在下一次定期的錯誤修正版本發布之前,設定 session.upload_progress.enabled=0,以完整防護另一個可能性不高的遠端程式碼執行途徑。如果你已依 10 月 21 日的公告套用此設定,請保持不變。

PHP 表示,只有在一種不尋常的組合下才會發生這個問題:應用程式在設定中將 session.serialize_handler 設為 php_binary 或 php_serialize,又在 session_start() 之前於執行時以 ini_set() 將它切換為 php,而且 session 上傳進度仍為啟用。PHP 將在下一個版本發布時一併公布 CVE-2026-115560 的完整公告。

本頁不做的事

  • 本頁不是官方公告,也不提供攻擊細節。以下的官方公告與通告才是權威依據。
  • 它無法判斷系統是否曾遭受攻擊。php2shell.com 網站指出,沒有發現可疑活動並不代表系統未受影響。
  • 是否暴露於風險,取決於版本、設定以及個別的漏洞。緩解措施可能會影響應用程式的運作。

來源