PHP 修補程式發布 10 小時後：受影響版本及各版本應採取的措施

PHP 發布修補程式 10 小時後：哪些版本受影響，各版本要怎樣處理？

作者：Nokka (นก-กา) | AI 及開源系統領域自由撰稿人 | 資料核實截至 2026年10月22日 07:40

本文由 AI (deepseek-v4.1-flash · 模型供應商：ollama-cloud) 透過 Hermes Agent 撰寫，並由人類監督及進行品質檢查 - Nokka (นก-กา)

昨晚修補程式已推出，今早就有人發動攻擊

昨日泰國時間 21:00，PHP 發布了一組修補程式，涵蓋四個版本的兩個漏洞：8.5.12、8.4.27、8.3.36 和 8.2.35 [1]

還不到一天，情況就從「做好準備」變成「有人開始發動攻擊」

要正確理解這段時間的新聞，就要分清以下三個層面，因為不同媒體報道的是不同層面

第一層：研究人員的示範 Sansec 表示，研究團隊已確認無需驗證身分即可成功發動攻擊，受影響的包括 Magento 2.4.9 和另外十款 PHP 應用程式；團隊亦指出，PHP 的預設設定也在受影響範圍內 [11]。PHP 團隊的公告亦指出，與 session 生命週期相關的 RCE 攻擊途徑，已在 mod_php 和 FPM 上獲得確認 [12]。

第二層：實際攻擊嘗試 watchTowr 向 SecurityWeek 表示，修補程式發布前後，公司感應器就開始收到攻擊流量，但尚未有任何攻擊成功 [3]。Hadrian 的説法更強烈，稱他們已在實際環境中看到 php2shell 被大規模用於攻擊，而最常見的途徑是 session upload progress 漏洞 [3]。Patchstack、Cloudflare 和 Vega 亦報告稱，各自的監察系統都收到同類攻擊 [3]。

第三層：已確認成功入侵伺服器 目前這一層仍然空白。watchTowr 威脅情報主管 Jake Knott 直言，截至目前仍未有人成功，但他不認為這種情況會維持太久 [3]。CISA 昨日發布警示，指出截至公告發布時，尚未發現任何攻擊 [2]。

這三個層面並不矛盾。在實驗室示範不等於實際入侵伺服器，而稱 php2shell 已在實際環境中用於攻擊，也仍然不同於確認成功入侵伺服器

給沒時間細讀的人看的簡短總結

如果你只記得一句，就記住這句

PHP 8.2 至 8.5 可立即更新至 8.2.35、8.3.36、8.4.27 或 8.5.12。至於 8.1、8.0 和 7.4，則要使用 source backport 或供應商提供的套件；7.3 至 5.x 則沒有 PHP 團隊提供的修補程式，也沒有官方 source backport。部分供應商可能有提供，應先向供應商查詢

哪些版本算是有問題

這個問題有三種不同答案，視乎你問的是誰。我認為這是最令人困惑的地方

答案一：PHP 維護團隊的説法

官方公告列出的範圍是 PHP 8.2 早於 8.2.35、PHP 8.3 早於 8.3.36、PHP 8.4 早於 8.4.27，以及 PHP 8.5 早於 8.5.12 [4]

我的理解是，這是他們已修補並確認的範圍，而不是所有受影響版本的範圍

公告另有提及一點：不同 SAPI 的風險並不相同。公告指出，mod_php 的風險最高，因為發生問題時 Apache 會無條件呼叫 shutdown；FPM 的條件則較多，必須有正在運行的應用程式觸發，而且要在合適時機發生 fatal error [1] [12]

答案二：中央資料庫的説法

NVD 在 10 月 21 日 14:17 UTC 登記了這兩個漏洞編號，並指出受影響範圍包括所有早於 8.2.35 的版本、8.3.0 至早於 8.3.36、8.4.0 至早於 8.4.27，以及 8.5.0 至早於 8.5.12 [5]

寫成「早於 8.2.35」而沒有標明起始版本，意思是所有更舊的版本都包括在內

答案三：發現漏洞的團隊的説法

Wiz Research 是發現這批漏洞的三個團隊之一。該團隊與 Ryan Austin 的 Calif 及 OpenAI 一同指出，過去十年推出的 PHP 版本幾乎全都有至少一個問題，範圍可追溯至 5.4 [6]

他亦指出，這組漏洞不只可執行程式碼，還能讀取程序的記憶體，當中可能包含密碼、API 權杖或其他請求的憑證，導致資料外洩 [6]。

按版本提供的處理指引

這部分我希望你慢慢閲讀，因為不同版本所需採取的措施確實不同。

如果你使用 PHP 8.5

更新至 8.5.12 [1]

這是獲全面支援的版本，也是與其他版本在同一晚發布修補程式的版本。

如果你使用 PHP 8.5，這個版本還有一項額外緩解措施：設定 fatal_error_backtraces=0，然後重新啟動所有 worker。PHP 指出，這能關閉一條已確認的攻擊途徑，但並非所有途徑 [1]。

如果你使用 PHP 8.4

更新至 8.4.27 [1]

8.4 會獲全面支援至 2026 年底，之後則進入只接收安全修補程式的階段，直至 2028 年底 [7]。也就是説，現在更新後，仍可再使用兩年多。

如果你使用 PHP 8.3

更新至 8.3.36 [1]

8.3 已進入只接收安全修補程式的階段，但仍完整獲得這次修補程式。

如果你使用 PHP 8.2

更新至 8.2.35 [1]

有一個日期值得記下：8.2 將於兩個月後，即 2026 年 12 月 31 日，結束接收安全修補程式 [7]。

如果你仍在使用 8.2，應計劃在本季升級至 8.4，因為 8.4 獲支援至 2028 年底，而 8.3 只會接收安全修補程式至 2027 年底 [7]。如果只能選擇一個升級目標版本，我會選 8.4。

如果你使用 PHP 8.1

PHP 已不再為 8.1 發布新版本，但安全團隊提供了 source backport，即 GitHub 上的分支 PHP-8.1-CVE-2026-109618-109619 [1] [8]。

source backport 意味著你必須自行取得程式碼並編譯，PHP 團隊沒有提供可下載的預先編譯二進制檔。

如果你使用提供長期支援的發行版，請先查詢供應商提供的套件，因為 PHP 指出，Linux 發行版供應商和 LTS 服務供應商已預先取得修補程式 [1]。

如果這兩種做法都不可行，CISA 建議在能夠修補或升級之前，先將系統從互聯網下線 [2]。

如果你使用 PHP 8.0 或 7.4

情況與 8.1 相同：有 source backport，但沒有可安裝的新版本；分支分別是 PHP-8.0-CVE-2026-109618-109619 和 PHP-7.4-CVE-2026-109618-109619 [1] [8]。

我閲讀公告後留意到，PHP 願意為兩個早已停止支援的版本提供 backport，反映團隊清楚知道仍有很多人停留在這些版本。

但自行編譯並非人人都能選擇，尤其是使用主機託管服務的人。

如果你使用 PHP 7.3 或更舊版本，包括 5.x

這裏我想直言：PHP 團隊沒有提供修補程式，也沒有提供官方 source backport。

PHP 的 backport 只到 7.4，沒有延伸至 7.3 或 5.x [1]；php.net 的 EOL 頁面亦指出，這些舊版本早已停止支援 [9]。

但這不代表完全沒有人會提供修補程式，因為 PHP 的公告本身指出，部分發行版供應商和 LTS 服務供應商可以自行回溯修補 [1]。如果你使用這類發行版，請先向供應商查詢，再作決定。

Wiz 指出，漏洞可追溯至 5.4 [6]；Sansec 則表示，漏洞影響執行 PHP 5.4 或以上版本的網絡伺服器，而存在漏洞的程式碼自 2012 年發布的 5.4.0 起便已包含在內 [11]。

可行的選擇包括升級至仍獲支援的版本、將系統從互聯網下線，或把系統放在 WAF 之後；CISA 指出，WAF 可以提供部分防護 [2]。至於放在 VPN 之後，則是我自己的建議，並非 CISA 的説法。

我認為這類用戶需要作出商業決策，而非技術決策，因為把使用 PHP 5 的網站升級至 8.x，可能需要修改大量程式碼。

如果你使用容器

Docker 官方的 php 映像檔已更新；docker-library/php 儲存庫中的 pull request 於 10 月 21 日 14:19 UTC 合併，即修補程式發布後 19 分鐘 [10]。

如果你把標籤固定在某個指定版本，例如 php:8.2-fpm，請拉取新的映像檔，並確認其中確實是 8.2.35，不要只相信標籤。

如果你使用共享主機或控制面板

你不是自行修補的人。要向服務供應商提出的問題有三個

• 我的網站正在使用哪個 PHP 版本？
• 計劃何時安裝 8.2.35、8.3.36、8.4.27 或 8.5.12？
• 如果目前使用的版本沒有修補程式，何時會遷移至受支援的版本？

我沒有資料得知泰國有哪些服務供應商已完成更新，因此無法判斷你是否安全。只能直接詢問。

如果暫時無法修補，可以先做甚麼

PHP 明確指出，沒有任何設定措施可以完全確保安全，而更新是唯一完整的解決方法 [1]

不過，有些措施可以降低特定攻擊途徑的風險。以下兩組措施按漏洞編號區分

CVE-2026-109618（OOM 漏洞）

透過 FPM pool 或 Apache 設定中的 php_admin_value 設定 memory_limit=-1，避免應用程式覆寫設定；並檢查是否有 pool 或目錄將其設回受限制的值 [1]

將 post_max_size 設得較低：如果沒有上載檔案，使用 8M；如果有上載檔案，使用 32M，並確保 upload_max_filesize 低於 post_max_size [1]

考慮在網頁伺服器或代理伺服器設定限制，包括解碼後計算的請求大小、欄位數量、multipart 中的 part 數量、header 數量及巢狀深度；這些限制亦須適用於沒有有效 Content-Length 的請求，因為攻擊者會利用這類請求繞過 post_max_size [1]

在容器中，以 cgroup 限制作為可用性界線，並設定政策，只終止出問題的 worker，而不是整個容器 [1]

而且不要以 RLIMIT_AS 或 RLIMIT_DATA 代替，因為 PHP 指出，這些限制會導致記憶體配置失敗，觸發有漏洞的攻擊途徑 [1]

CVE-2026-109619（狀態卡住漏洞）

設定 session.upload_progress.enabled=0，然後重新啟動所有 worker；設定必須透過 php.ini、FPM 或伺服器設定完成，並在讀取請求前生效。不要依賴 ini_set() 或 .user.ini [1]

這項措施會封鎖已確認的 session 攻擊途徑，但無法封鎖所有情況 [1]

如果你使用 FPM，並且能接受效能方面的影響，公告亦建議設定 pm.max_requests=1，避免同一個 worker 處理下一個請求，從而減少狀態在不同請求之間持續存在的機會 [12]

並移除無效或已棄用、會在每個請求中使用且在請求開始前引發警告的 ini 設定，因為使用 error_reporting、display_errors 或 @ 隱藏訊息並無幫助 [1]

公告最後指出，應修正攻擊者能觸發的 fatal error 和執行逾時問題，包括上載或匯入 callback，以及請求完成後的清理程序 [1]

範例：檢查設定是否已生效

最直接的方法是在使用 FPM 或 mod_php 的網站中放置臨時 probe 檔案，然後透過瀏覽器開啟

<?php
var_dump(ini_get('memory_limit'), ini_get('post_max_size'),
         ini_get('upload_max_filesize'), ini_get('session.upload_progress.enabled'));

查看後立即刪除檔案，因為任何能開啟這個檔案的人都能看到伺服器設定

以下命令只會顯示 PHP 命令列的參考值，並非網站實際使用的值

php -i | grep -E "memory_limit|post_max_size|upload_max_filesize"

檢查是否已遭入侵

CISA 建議監察會呼叫 shell 或下載工具的 PHP worker 程序 [2]

如果發現沒有合理原因的程序，先將該電腦從網絡隔離，再收集證據

我建議收集以下資料，這是我個人的建議，並非來自任何公告：至少過去 24 小時的 access log，這個時段涵蓋修補程式發布前後；PHP-FPM log；網頁目錄中已修改檔案的清單；以及新增的排程工作清單

之後再尋找攻擊者常留下的痕跡：可執行命令的檔案、被插入異常程式碼行的原始碼，以及新建立的用戶帳戶

由於這個漏洞仍可讀取記憶體 [6]，如果你懷疑已遭入侵，應假設該電腦上的密碼、token 和 key 已外洩，並輪換這些資料

我自行查閲了甚麼，以及尚未查閲的內容

我開啟了 php.net 上的公告並閲讀全文，包括風險緩解措施和 source backport 清單 [1]

我開啟了 NVD 上兩個 CVE 的紀錄，並核實其中列出的版本範圍 [5]

我在 php-src 儲存庫查看了兩份安全公告，第一份 GHSA-w8hw-w9fx-j79w 談及 OOM 本身，另一份 GHSA-6wmf-4rv5-p3rp 談及狀態卡住的問題，然後閲讀了兩者的技術摘要 [4] [12]

我查看了 CISA 於 10 月 21 日發布的公告，並閲讀了全部建議 [2]

我查看了 Wiz Research 的研究，閲讀當中有關影響範圍可追溯至 5.4，以及記憶體讀取的內容 [6]

我檢查了 docker-library/php 的 pull request，並確認它於 10 月 21 日 14:19 UTC 合併

我尚未檢查的事項 我沒有親自測試漏洞或修補程式，也沒有可供測試的實驗室

我沒有查核泰國有哪些託管服務商已經更新

我也沒有核實 Wiz 提到的「全球 70% 網站」這個數字，因為這是該供應商提供的數字，並非我自行量度的統計數據

我想留給系統管理員的問題

如果你管理數十個網站，問題不在於「修補了嗎」，而在於「你知道總共有多少個網站，以及各自使用甚麼版本嗎？」

因為在修補程式發布的當晚，令用戶往往未能及時修補的原因，通常不是安裝有多困難，而是不知道自己手上有哪些東西

參考資料

[1] The PHP Development Team，「安全公告：嚴重遠端程式碼執行漏洞，請立即更新」，php.net News Archive，2026 年 10 月 21 日（8.5.12 · 8.4.27 · 8.3.36 · 8.2.35 · 受影響的 SAPI · 兩個 CVE 的詳細資料 · 7.4、8.0、8.1 的 source backport · 緩解措施 memory_limit、post_max_size、session.upload_progress、fatal_error_backtraces · 不要使用 RLIMIT_AS/RLIMIT_DATA）。 https://www.php.net/archive/2026.php#2026-10-21-5

[2] CISA，「PHP 存在嚴重漏洞，必須立即修補」，2026 年 10 月 21 日（建議更新至 8.5.12、8.4.27、8.3.36 或 8.2.35 · 截至發布時尚未發現攻擊 · 建議盤點 · 使用 8.1 或更舊版本的系統應先離線，直至完成修補 · WAF 可提供部分防護 · 留意 PHP worker 是否呼叫 shell）。 https://www.cisa.gov/news-events/alerts/2026/10/21/critical-vulnerabilities-php-require-immediate-patching

[3] Ionut Arghire，「PHP2Shell 修補程式推出之際，感測器首次捕捉到攻擊嘗試」，SecurityWeek，2026 年 10 月 21 日（watchTowr 在修補程式發布前後發現攻擊嘗試，但尚未有成功個案 · Jake Knott 的説法 · Hadrian 發現大規模攻擊及 session upload progress 路徑 · Patchstack、Cloudflare、Vega 發現攻擊嘗試 · 影響範圍可追溯至 5.4 · 記憶體讀取）。 https://securityweek.com/php2shell-patches-land-as-first-exploitation-attempts-hit-sensors/

[4] PHP Security Team (bukka)，「透過 OOM 損毀實現 RCE」，GHSA-w8hw-w9fx-j79w，2026 年 10 月 21 日（受影響版本：早於 8.2.35 · 8.3.0 至早於 8.3.36 · 8.4.0 至早於 8.4.27 · 8.5.0 至早於 8.5.12 · 已修補版本：8.2.35、8.3.36、8.4.27、8.5.12 · 透過 multipart 觸發 OOM 的機制 · mod_php 無條件呼叫 shutdown · FPM 在啟動失敗時退出 child · FrankenPHP 和 LSAPI）。 https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w（CVE-2026-109619 的配對公告是 GHSA-6wmf-4rv5-p3rp）

[5] NIST，National Vulnerability Database，CVE-2026-109618 和 CVE-2026-109619，於 2026 年 10 月 21 日 14:17 UTC 發布（CVSS v4.0 9.2 · CVSS v3.1 9.8 · CPE 範圍：早於 8.2.35、8.3.0 至早於 8.3.36、8.4.0 至早於 8.4.27、8.5.0 至早於 8.5.12）。 https://nvd.nist.gov/vuln/detail/CVE-2026-109618 · https://nvd.nist.gov/vuln/detail/CVE-2026-109619

[6] Sagi Tzadik 等人，《PHP2Shell：AI 揭示影響互聯網 70% 的嚴重 RCE 漏洞》，Wiz Blog，2026年10月21日（PHP 5.4 及之後幾乎所有版本都至少存在一項問題 · 可讀取程序記憶體 · 利用 AI 模型協助搜尋漏洞 · 70% 是該供應商提供的數字）。 https://www.wiz.io/blog/php2shell-php-rce

[7] The PHP Group，《支援版本》，php.net，2026年10月22日查閲（8.2 的安全支援期於 2026年12月31日結束 · 8.3 至 2027年12月31日 · 8.4 至 2028年12月31日 · 8.5 至 2029年12月31日）。 https://www.php.net/supported-versions.php

[8] php-src，原始碼回移分支，GitHub，2026年10月22日查閲（PHP-7.4-CVE-2026-109618-109619 · PHP-8.0-CVE-2026-109618-109619 · PHP-8.1-CVE-2026-109618-109619）。 https://github.com/php/php-src/branches/all

[9] The PHP Group，《不受支援的分支》，php.net，2026年10月22日查閲（7.4 於 2022年11月28日結束支援 · 7.3 於 2021年12月6日結束支援 · 5.6 於 2018年12月31日結束支援）。 https://www.php.net/eol.php

[10] docker-library/php，《更新至 8.5.12、8.4.27、8.3.36、8.2.35》，pull request 1694，於 2026年10月21日 14:19 UTC 合併。 https://github.com/docker-library/php/pull/1694

[11] Sansec Forensics Team，《PHP2Shell：PHP 中的嚴重 RCE 與記憶體資料洩漏》，Sansec Threat Research，2026年10月21日（影響執行 PHP 5.4 或以上版本的網頁伺服器 · 易受攻擊的程式碼自 2012 年的 5.4.0 起已存在 · 已確認可在 Magento 2.4.9 及另外十款 PHP 應用程式上進行無須驗證的 RCE · mod_php 和 FPM 均受影響 · 預設設定亦受影響 · 即使應用程式沒有呼叫 session_start，也可能讀取記憶體）。 https://sansec.io/research/php2shell

[12] PHP Security Team (bukka)，《透過殘留的全域狀態進行 RCE》，GHSA-6wmf-4rv5-p3rp，2026年10月21日（受影響版本：低於 8.2.35 · 8.3.0 至低於 8.3.36 · 8.4.0 至低於 8.4.27 · 8.5.0 至低於 8.5.12 · 4 個版本已修補 · 同一 worker 內跨請求的狀態殘留機制 · 緩解措施：session.upload_progress.enabled=0 和 fatal_error_backtraces=0）。 https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp