PHP2Shell漏洞安全報告：受影響版本與修復方案

簡短回答：PHP2Shell 是 PHP 引擎本身兩個嚴重漏洞（CVE-2026-109618 與 CVE-2026-109619）的統稱，PHP 官方已於 2026年10月21日發佈緊急修復版本。未經身份驗證的攻擊者只要能訪問 PHP 網站服務器，就可能在其上執行代碼。請升級到 PHP 8.5.12、8.4.27、8.3.36 或 8.2.35，重啓所有 PHP 工作進程，並找出你不知道自己在運行的 PHP。

PHP2Shell 漏洞是什麼？一段話講清楚

2026年10月21日，PHP 項目一次性發布四個安全版本（8.5.12、8.4.27、8.3.36 和 8.2.35），修復解釋器核心請求處理邏輯中的兩個遠程代碼執行（RCE）漏洞，業界稱之為 PHP2Shell。PHP 項目對這兩個漏洞的評分均為 CVSS v4.0 9.2 分（嚴重）。其安全公告指出，風險適用於“所有處理網頁請求的 PHP 安裝”，無論 PHP 是以 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 還是 LiteSpeed 方式運行。漏洞細節在原定披露日的前一天提前泄露，補丁窗口因此比平常短得多。數小時內，多家安全公司就報告了攻擊嘗試。到10月22日至23日，美國 CISA、英國 NCSC、新加坡網絡安全局（CSA）和香港 HKCERT 均已發佈警報。

本文梳理目前已知的事實、仍不確定之處，以及香港、中國內地和新加坡的 IT 或安全負責人在未來 24 小時、72 小時和 7 天內應當做什麼。它面向需要拍板和落實的人，而不只是工程師。

CVE-2026-109618 和 CVE-2026-109619 具體是什麼？

兩個漏洞都位於 PHP 本身，處在 WordPress、Drupal、Laravel、Magento 或任何插件之下。把應用程序更新到最新版本並不能保護你，只有更新 PHP 運行時才行。

CVE-2026-109618：記憶體耗盡破壞導致的遠程代碼執行

PHP 的安全公告（GitHub 公告 GHSA-w8hw-w9fx-j79w）這樣描述：記憶體耗盡（out-of-memory）處理可能在內部請求數據只初始化了一部分時中斷 PHP，隨後請求清理代碼可能把這份未構建完成的數據當作有效數據處理。如果攻擊者能在恰當時機讓某個 PHP 工作進程陷入記憶體耗盡狀態，就可能把這種混亂轉化為對該進程的控制。Google 的響應指南提到，攻擊者可能利用體積很大的請求載荷來觸發記憶體耗盡。

CVE-2026-109619：殘留全局狀態導致的遠程代碼執行

第二份公告（GHSA-6wmf-4rv5-p3rp）描述的是：請求所屬的內部狀態在其記憶體被釋放後依然留存。同一 PHP 工作進程處理的後續請求，可能在正常啓動流程重置之前就用到這份殘留狀態。新加坡 CSA 將其歸類為釋放後使用（use-after-free）漏洞。由於 PHP 工作進程壽命很長、會處理大量請求，一位訪客的請求就可能影響同一進程上的下一個請求。

誰面臨的風險最高？

PHP 項目表示，使用 Apache 搭配 mod_php 的風險最高。針對這種環境，已有演示性的利用方式：未經身份驗證的請求就能在任何應用代碼運行之前觸發攻擊。這一點至關重要。登入頁面、寫在代碼裡的應用層防火牆、加固過的 CMS 配置，都幫不上忙，因為攻擊發生在這些機制執行之前。多倫多大學的公告補充說，CVE-2026-109619 在 PHP-FPM 路徑上需要配合合適的應用操作，這提高了利用難度，但並不意味著安全。

嚴重程度到底如何？

PHP 項目：兩個漏洞均為 CVSS v4.0 9.2 分（嚴重）。
部分公開漏洞數據庫：CVE-2026-109618 的 CVSS v3.x 評分為 9.8，CVE-2026-109619 為 8.1。
watchTowr：考慮到 PHP 部署之廣、攻擊者所需條件之少，將其視為 10.0 分。

評分有高有低，結論並無二致：互聯網暴露的網站服務器上出現未經身份驗證的遠程代碼執行，就應當放下手頭一切工作來處理。

時間線：從發現到被實際利用

公開報道仍在不斷更正，因此下面的時間線只採用至少有一份一手或可靠來源報告證實的日期。所有時間均為 UTC。

2026年8月：研究人員各自獨立發現這些漏洞。公開報道稱功勞歸於 Calif 和 Wiz 的團隊，二者都使用了 AI 輔助分析。據報道，其中一個底層的記憶體耗盡問題在 2024 年的一次審計中就曾被注意到，但一直沒有修復。
2026年10月17日：Amazon Threat Intelligence 後來報告稱，其蜜罐遙測數據中自這一天起就出現了利用嘗試，比公開披露早了四天。
2026年10月20日：細節在 Hacker News 上泄露，早於原定的10月22日披露。PHP 項目宣佈將於10月21日 14:00 UTC 緊急發佈版本。
2026年10月21日 13:34 UTC：兩份 GitHub 安全公告公開，略早於計劃的發佈時間。
2026年10月21日：PHP 8.5.12、8.4.27、8.3.36 和 8.2.35 發佈，併為 8.1、8.0 和 7.4 提供了最小化的源碼回移補丁。新加坡 CSA 和美國 CISA 發佈警報。watchTowr 報告其蜜罐網絡遭到利用嘗試，Cloudflare 報告出現早期攻擊嘗試並部署了臨時 WAF 規則。
2026年10月22日：HKCERT 發佈警告，敦促香港企業檢查並修補 PHP 系統。CSA 更新警報。Google Cloud 更新其 WAF 與檢測指南。截至當日，這兩個 CVE 尚未被列入 CISA 的已知被利用漏洞（KEV）目錄。
2026年10月23日：HKCERT 更新其10月22日首發的安全公告，將此事件評為極高風險，並表示這些漏洞正在被實際利用。

結論很清楚：從披露到遭受攻擊，間隔現在以小時計，而不是以周計。HKCERT 也指出了同一點：AI 工具正在縮短漏洞披露、掃描和嘗試利用之間的時間。

哪些 PHP 版本受影響、哪些已修復？

所有仍在維護的分支在更新之前都受影響，幾乎所有更舊的版本也是如此。

PHP 8.5：8.5.12 之前受影響，8.5.12 已修復。
PHP 8.4：8.4.27 之前受影響，8.4.27 已修復。
PHP 8.3：8.3.36 之前受影響，8.3.36 已修復。
PHP 8.2：8.2.35 之前受影響，8.2.35 已修復。請注意，PHP 8.2 將於2026年12月31日終止支援（EOL）。
PHP 8.1、8.0 和 7.4：受影響，且已終止支援。官方沒有發佈二進制版本，PHP 項目只提供了最小化的源碼回移補丁，部分 Linux 發行版和長期支援（LTS）廠商會提供已打補丁的軟件包。
PHP 7.3 及更舊版本（包括 PHP 5.x）：受影響，且沒有修復。唯一穩妥的做法是升級到仍受支援的分支，或把系統從互聯網上下線。

有兩個實際操作中的陷阱，常讓團隊踩坑：

廠商回移補丁會保留舊版本號。在已打補丁的發行版或控制面板構建中，`php -v` 可能仍顯示舊版本。請查看廠商的更新日誌或安全公告，確認其中同時列出了兩個 CVE 編號，以此判斷是否已修復。
並非所有軟件源在第一天就完成更新。PHP 項目特別提醒第三方軟件源 rpms.remirepo.net 的用戶，改用發行版自帶軟件包或從源碼編譯，因為該軟件源在發佈當天不會有更新。

為什麼這對香港、中國內地和新加坡的企業很重要？

PHP 支撐著很大一部分網站。HKCERT 引用的報告稱，超過 75% 的網站使用 PHP，並估計聯網的 PHP 主機約有 510 萬台。但對大多數亞洲企業而言，更大的風險並非主站，而是那些他們並不知道存在的 PHP。

PHP 藏在資產清單覆蓋不到的地方

HKCERT 提醒，PHP 可能內置於應用程序、網絡與安全設備、存儲系統和監控系統的管理界面及運維組件中。這些內嵌的 PHP 往往與操作系統的 PHP 版本不同，常規的資產盤點因此會漏掉它們。典型的排查位置包括：

虛擬主機控制面板：例如 cPanel、Plesk、HestiaCP 和 VestaCP，它們自帶 PHP 構建。
老舊的內網系統及人事、預訂或工單工具：多年前由本地服務商開發，從未升級到 PHP 7 以上。
網絡、防火牆、VPN、NAS 和監控設備：帶有基於 PHP 的網頁控制檯。
營銷網站和電商店鋪：基於 WordPress、WooCommerce、Magento 或 OpenCart，通常由第三方託管。
容器與鏡像：內含 PHP，卻很少重新構建。

監管機構和保險公司會來問

對受監管的企業來說，這也是一個舉證問題。新加坡 CSA 建議各機構審查所有運行 PHP 的系統，優先處理面向互聯網的服務器，並檢查間接捆綁的組件。受香港金管局（HKMA）或證監會（SFC）監管的企業，以及須履行等保（MLPS）義務的內地業務，都應預期審計人員、客戶和網絡安全保險公司會問一個簡單的問題：你什麼時候知道的，修補了什麼，如何證明？帶日期的補丁記錄、掃描結果和保存完好的日誌可以回答這個問題，“我們覺得沒問題”不行。

現在該怎麼做？24 小時、72 小時和 7 天行動計劃

以下步驟依據 PHP 項目的安全公告，以及 HKCERT、CSA 和 CISA 的指引整理。請把它們當作先後順序，而不是可選菜單。

24 小時內：找出來、打補丁、重啓

盤點你擁有或託管的每一個 PHP 運行時。先從面向互聯網的服務器開始，把控制面板、設備、容器和第三方託管的網站都算上。以書面形式向每家網站寄存商和軟件廠商詢問其補丁狀態。
升級到已修復的版本。安裝 PHP 8.5.12、8.4.27、8.3.36 或 8.2.35，或者採用發行版、控制面板廠商提供的已修復軟件包。Ubuntu 和 SUSE 等已發佈更新。
重啓所有 PHP 工作進程。舊進程不退出，修復就不會生效。請重啓 PHP-FPM 進程池、使用 mod_php 的 Apache，以及任何長期運行的 PHP 進程。容器要重新構建並重新部署；基礎鏡像已打補丁，但容器仍在運行的話，等於沒打。
優先修補 mod_php。Apache 搭配 mod_php 風險最高，這類服務器排在隊列最前面。
凡使用廠商回移補丁的，按 CVE 編號而不是版本號來驗證修復。

今天無法打補丁：先縮小暴露面

PHP 項目明確表示，沒有任何配置變更能完全緩解這些漏洞。臨時措施只能收窄特定的攻擊路徑。如果某個系統無法在數小時內更新，請儘可能多地採取下列措施，同時仍要安排升級：

讓它下線或隔離。HKCERT 和 watchTowr 都建議，對無法立即修補的 PHP 系統，限制或取消其公網訪問。這是唯一能消除風險（而不只是降低風險）的臨時措施。
針對 CVE-2026-109619：在 `php.ini`、FPM 進程池或服務器配置中設定 `session.upload_progress.enabled=0`，然後重啓所有工作進程。不要依賴 `ini_set()` 或 `.user.ini`。在 PHP 8.5 上，還要設定 `fatal_error_backtraces=0`。
針對 CVE-2026-109618：在網頁服務器或代理層限制請求大小，包括請求體大小、字段數量、multipart 分段數量、請求頭數量和嵌套深度。把 `post_max_size` 保持在較低水平（公告建議無上傳時設為 8M，有上傳時設為 32M）。通過容器或 cgroup 記憶體限制來約束工作進程，使其只終止受影響的那個進程。公告還提到可以設定 `memory_limit=-1`，但同時警告，僅靠這一項並不能讓安裝變得安全。
如有託管式 WAF 規則，請啓用。Cloudflare 已部署臨時規則；Google Cloud 建議使用 Cloud Armor 託管規則並設定請求體檢查上限。把這些視為安全帶，而不是修復。例如 CloudLinux 就指出，其防火牆規則暫時還無法覆蓋兩條攻擊路徑中的一條。

72 小時內：排查是否已經中招

利用嘗試自10月21日起就有報告，Amazon 報告的最早一次嘗試可追溯到10月17日。打補丁是關上門，但不能告訴你之前有沒有人進來過。

在日誌輪轉之前留存日誌。至少保留10月中旬以來的網頁服務器、PHP-FPM、WAF 和防火牆日誌。CSA 特別建議回溯檢查到10月中旬的日誌。
查找異常請求和進程行為。留意體積過大或格式異常的請求、集中出現的記憶體耗盡錯誤或工作進程崩潰，以及 PHP 或網頁服務器進程衍生出 shell 或意外的子進程。
檢查持久化痕跡。查看網站根目錄和上傳目錄裡是否有新增或被改動的 PHP 文件，是否有不明的定時任務、新的本地帳戶和意外的對外連接。英國 NCSC 特別提醒各機構留意後門。
發現異常就升級處置。如果發現入侵跡象，請隔離主機、保全證據並引入事件響應團隊。從已知乾淨的鏡像重建，比在線清理服務器更穩妥。

7 天內：補上結構性缺口

淘汰 PHP 8.1 及更舊的版本。回移補丁只是爭取時間，無法讓已終止支援的分支長期保持安全。由於 PHP 8.2 將於2026年12月31日終止支援，也要規劃遷移。
補上資產盤點的缺口。如果這次事件讓你發現了自己並不知道的 PHP，說明你的資產登記冊並不完整。把內嵌系統和由廠商管理的系統加進去。
給補丁設定時限。對面向互聯網的嚴重漏洞，定下書面的修復時間目標，以小時而不是下一個維護窗口為單位，並按此彙報。
記錄你做了什麼。保留一份帶日期的記錄，涵蓋資產盤點、補丁時間、驗證情況和日誌審查。董事會、監管機構、客戶和保險公司都會要求提供這份證據。

打補丁、回移補丁、緩解還是隔離：哪種方案適合你？

大多數環境會同時用到其中幾種。以下是它們的對比。

四種應對方式對比

官方更新（8.5.12、8.4.27、8.3.36、8.2.35）：同時修復兩個漏洞。需要重啓，並做一次快速的應用冒煙測試。這是唯一完整的修復方式，也是所有受支援系統的預設選擇。
廠商或發行版回移補丁：在不做大版本升級的前提下，修復舊分支上的兩個漏洞。取決於廠商的支援情況；由於版本號可能不變，請按 CVE 編號驗證。對 PHP 8.1、8.0 或 7.4 來說是合理的過渡方案，但不是最終歸宿。
配置緩解與 WAF 規則：幾分鐘內就能收窄特定攻擊路徑。按 PHP 項目自己的說法並不完整，還可能影響正常的上傳或進度條功能。只在準備更新期間使用。
隔離或臨時關停：徹底消除互聯網暴露，代價是可用性。適用於 PHP 7.3 及更舊版本、無法打補丁的設備，以及任何一天內無法更新的系統。歐洲和加拿大的若干公共機構在最初 48 小時內選擇了這條路。

更大的教訓：AI 壓縮了補丁窗口

PHP2Shell 與普通的嚴重漏洞有兩點不同。其一，這些漏洞是藉助 AI 輔助工具發現的，而攻擊者手裡也有同樣的工具。其二，資訊外洩加上已修復版本提前發佈，意味著攻擊者數小時內就能對比新舊代碼。HKCERT 自己的標題已直接點明：AI 同時在加速攻擊與防禦，並縮短了響應窗口。

對中型企業而言，實際後果是：“我們每月第二個星期二打補丁”已不足以作為面向互聯網系統的安全策略。真正保護你的，是一條無論哪一天都能運轉的短鏈條：

知道自己在運行什麼。保持實時更新的資產清單，包括內嵌軟件和第三方託管的軟件。
看清哪些暴露在外。定期進行外部漏洞掃描，讓嚴重問題先於攻擊者被你發現。
給補丁設定時限。為嚴重漏洞的修復指定負責人並設定書面的時間目標，包含重啓和驗證步驟。
盯住攻擊企圖。保留日誌並做好監控，讓利用嘗試能夠被看到，而不是等收到勒索信才知道。

Brocent 能提供哪些幫助？

Brocent 為香港、中國內地、新加坡及更廣泛的亞太地區企業提供管理型IT外判服務和網絡安全服務。針對 PHP2Shell 這類事件，相關的服務包括：

暴露面檢查：通過外部漏洞掃描找出面向互聯網的 PHP 及其他嚴重暴露點，或選擇範圍更廣的 IT 安全評估。
給補丁設定時限：管理型漏洞掃描與補丁管理，並提供補丁合規報告。如果只需要這項服務，請參閱補丁管理定價。
資產盤點與加固：通過 IT 評估與審計，把內嵌系統、控制面板和老舊應用納入同一份登記冊，並規劃如何從已終止支援的 PHP 遷出。
邊界防護：網絡安全方案，包括防火牆和 WAF 規則，在系統完成更新之前作為補償性控制措施。

如果你不確定自己環境中的某個系統是否受影響，歡迎聯繫 Brocent，我們的團隊會協助你逐項落實上述清單。

常見問題

PHP2Shell 是什麼？

PHP2Shell 是 CVE-2026-109618 和 CVE-2026-109619 的通用稱呼，指 PHP 解釋器中的兩個嚴重漏洞，於2026年10月21日披露並修復。它們可能使未經身份驗證的攻擊者在運行 PHP 並處理網頁請求的服務器上執行代碼。

更新 WordPress、Drupal 或插件能解決問題嗎？

不能。漏洞存在於 PHP 引擎本身，位於應用程序之下。只有更新 PHP 運行時，或使用回移了修復的廠商軟件包，才能封堵它們。CMS 和插件當然也要保持更新，但那是另一項獨立的工作。

哪些 PHP 版本修復了 PHP2Shell？

PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。對於 PHP 8.1、8.0 和 7.4，請使用同時列出兩個 CVE 編號的發行版或長期支援廠商軟件包。PHP 7.3 及更舊版本沒有修復，應升級或隔離。

PHP2Shell 正在被利用嗎？

是的，多個來源都有報告。watchTowr 和 Cloudflare 報告自2026年10月21日起出現利用嘗試，Amazon 報告了日期為10月17日的一次嘗試，HKCERT 於10月23日更新的公告則指出這些漏洞正在被實際利用。截至10月22日，CISA 尚未把任一 CVE 列入已知被利用漏洞目錄，因此局勢仍在發展。