PHP2Shell：這個 PHP 漏洞是甚麼，如何修補

PHP2Shell 是 PHP 本身的兩個嚴重漏洞，編號為 CVE-2026-109618 及 CVE-2026-109619。這兩個 PHP 漏洞可令未經登入的攻擊者，在任何提供 PHP 網頁的伺服器上執行程式碼。修復方法是更新 PHP：升級至 8.5.12、8.4.27、8.3.36 或 8.2.35，或安裝發行版的已修補套件，然後重新啟動每一個 PHP worker。

漏洞細節於 10 月 20 日外洩，比原定的披露日期早了兩天，PHP 項目因此提前一天，在 10 月 21 日發布修復版本。若你有任何系統運行於 PHP 之上（WordPress、WooCommerce、Drupal、Magento、Laravel、控制台），請今天就檢查版本。

甚麼是 PHP2Shell 漏洞？

PHP2Shell 是研究人員為 PHP 執行環境中兩個遠端執行程式碼（RCE）漏洞所起的名稱。漏洞由 Calif、Wiz、OpenAI 及 Quarkslab 的研究人員報告，PHP 將兩者均評為 CVSS v4.0 9.2 分。

這些漏洞位於 PHP 解析傳入請求的環節，發生在你的應用程式碼開始執行之前。更新 WordPress、外掛或框架對此毫無作用，必須更換的是 PHP 執行檔本身。

PHP 的安全公告列出所有處理網頁請求的部署方式：PHP-FPM、使用 mod_php 的 Apache、php-cgi、FrankenPHP 及 LiteSpeed。公告將使用 mod_php 的 Apache 評為風險最高，並已有實際示範的攻擊：只需一個未經驗證的請求，就能在任何應用程式碼執行之前觸發攻擊。公告亦描述了另一條途徑：在適當的應用程式條件下，可透過 PHP-FPM 上的 session 上傳進度功能遠端執行程式碼。

哪些 PHP 版本受影響？

四個修復版本之前的所有版本。以下是 PHP 安全公告及其 10 月 21 日安全版本的說明：

Cloudflare 及 Imperva 表示，這些漏洞可追溯至 PHP 5.4。PHP 公告將修復版本以下的所有版本列為受影響，但沒有指明最早受影響的版本。

你的版本號看似舊，但可能已經修補。 Linux 發行版會向後移植修補，同時保留原來的上游版本號。Ubuntu 24.04 以 8.3.6-0ubuntu0.24.04.13 提供修復，版本卻仍顯示為 8.3.6。Debian 12 為 8.2.35-1~deb12u1（DLA-4848-1），Debian 13 為 8.4.27-1~deb13u1（DSA-6574-1）。請以完整的套件版本號對照發行版的安全追蹤頁面，而不是只看前三個數字。

PHP2Shell 是否已被利用？

各方報告並不一致，而且每小時都在變化。以下按時間順序列出各來源的說法：

• 10 月 17 日： Amazon Threat Intelligence 在其 MadPot 誘捕系統上記錄到一次 PHP2Shell 攻擊嘗試，比修補發布早了四天。該請求來自一個與商業匿名化服務相關的 IP 地址。
• 10 月 20 日： 漏洞細節在網上外洩。watchTowr 確認漏洞屬實。Huntress 表示未見任何利用活動，亦不知道有公開的攻擊程式碼。
• 10 月 21 日 03:02 UTC： Cloudflare 啟用了針對 PHP2Shell 的 WAF 規則。該公司其後表示，觀察到針對其客戶的攻擊流量，攻擊者亦不斷修改攻擊載荷，試圖繞過規則。
• 10 月 21 日 14:00 UTC： PHP 發布修復版本。watchTowr 同日報告，其誘捕網絡上出現針對兩個漏洞的利用活動。
• 10 月 21 日下午（美國時間）： PHP Foundation 的執行董事向 CNBC 表示，並無證據顯示存在可用的攻擊程式，只有「不完整、方向錯誤且無法運作的生成程式」。Imperva 則報告，其披露前的監測中未見相符的流量。
• 10 月 23 日： 兩個 CVE 均尚未列入 CISA 的已知被利用漏洞（KEV）目錄（該目錄最後更新於 10 月 21 日）。

研究人員已構建出可用的攻擊程式，其他團隊亦表示已重現這些漏洞。請假設攻擊者同樣做得到，並將所有未修補、面向互聯網的 PHP 伺服器視為已暴露於風險之中。

如何檢查 PHP 版本

請檢查處理網頁請求的 PHP。在很多伺服器上，命令列使用的 PHP 與網站背後的 PHP 並不是同一個版本。

在伺服器上：

php -v                     # command line PHP
php-fpm8.3 -v              # the FPM build (the name varies: php-fpm, php-fpm8.4)
apachectl -M | grep php    # a php_module line means Apache runs PHP as mod_php
dpkg -l | grep php         # Debian/Ubuntu: the full package versions
rpm -qa | grep php         # RHEL, Rocky, Alma, Fedora

透過瀏覽器： 在網站根目錄放置一個名為 info.php 的檔案，內容為 <?php phpinfo();，然後開啟它，查看頂部的版本號及 Server API 一行（它會顯示 FPM、Apache 2.0 Handler 或 CGI）。查看後請立即刪除該檔案，因為它會顯示你的完整設定。

在 WordPress 中： 前往工具 > 網站健康狀態 > 資訊（Tools > Site Health > Info），展開伺服器（Server）。PHP 版本一行就是你網站運行的版本。

在寄存控制台中： cPanel 在 MultiPHP Manager 或 Select PHP Version 中顯示，Plesk 在網域的 PHP 設定中顯示，大多數代管寄存商則在網站的概覽頁面顯示。

在 Docker 中： docker exec <container> php -v 會顯示正在運行的容器內的 PHP 版本，這才是真正需要看的版本。

若要從外部測試，據 Help Net Security 報道，Searchlight Cyber 已發布一個開源檢查工具 php2shell-scanner。請只對你擁有的主機執行。

如何修補 PHP2Shell

適用於所有技術架構的次序：先處理面向互聯網的伺服器，然後重新啟動每一個 PHP 程序。只要舊的 worker 仍在處理請求，磁碟上已修補的執行檔就不會生效。

Debian 及 Ubuntu

sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm   # match your version
sudo systemctl restart apache2      # if you use mod_php

然後以 dpkg -l | grep php 檢查套件版本，並對照 Debian 或 Ubuntu 的安全追蹤頁面。在 Ubuntu 20.04 及更舊的版本上，已修復的 7.x 套件透過 Ubuntu Pro 提供。第三方軟件庫按各自的時間表更新：Help Net Security 報道，rpms.remirepo.net 在發布當日尚未更新，因此在依賴第三方軟件庫之前，請先確認它已推出更新。

RHEL、Rocky、AlmaLinux 及 Fedora

執行 sudo dnf upgrade 'php*'，然後重新啟動 php-fpm 及 httpd。請查閱供應商的安全公告，以確認已修復的套件版本，因為它不會與上游版本號相同。

Docker 映像

Docker Hub 上的官方 php 映像已於 10 月 21 日加入 8.5.12、8.4.27、8.3.36 及 8.2.35 標籤。請固定使用其中一個，重新建置並重新部署：

FROM php:8.4.27-fpm

docker compose build --pull && docker compose up -d

正在運行的容器會一直使用舊的 PHP，直至你將其替換為止。以 php 為基礎建置的映像（包括 wordpress）同樣需要重新拉取並重新部署。

共享寄存及 cPanel

在這種環境下，你無法自行修補 PHP。寄存商會更新控制台提供的 PHP 版本（大多數 cPanel 伺服器上為 EasyApache 的 ea-php 或 CloudLinux 的 alt-php）。請查看寄存商的狀態頁面，或向技術支援查詢其 PHP 版本是否已包含 CVE-2026-109618 及 CVE-2026-109619 的修復。若你的網站仍在使用 7.4 或 8.1，請在 MultiPHP Manager 或 Select PHP Version 中切換至 8.3 或更新版本；如有測試用的網站副本，請先在副本上測試。

代管 WordPress 寄存

寄存商會為你修補 PHP。WordPress.org 表示，這些漏洞不需要、亦沒有計劃推出 WordPress 更新。請先確認寄存商已推出修復，然後檢查網站健康狀態 > 資訊 > 伺服器。若網站仍使用 PHP 8.1 或更舊的版本，請升級，因為這些分支只會獲得供應商的向後移植修補。

Windows 及自行編譯

已修復的原始碼及 Windows 執行檔可在 php.net 的下載頁面取得。對於 7.4、8.0 及 8.1，PHP 為自行編譯 PHP 的使用者發布了最小化的原始碼向後移植修補。

如果今天無法修補

PHP 在這一點上說得很直接：只有更新才是完整的修復。其安全公告列出了一些設定，可阻擋特定的攻擊途徑，但不能令伺服器變得安全：

• 在 php.ini、FPM pool 或伺服器設定中（而不是 ini_set() 或 .user.ini）設定 session.upload_progress.enabled=0，然後重新啟動每一個 worker。這可阻擋已確認的 session 攻擊途徑。
• 在 PHP 8.5 上，設定 fatal_error_backtraces=0 並重新啟動每一個 worker。
• 以應用程式無法覆寫的方式設定 memory_limit=-1，例如使用 php_admin_value。同時配合較低的 post_max_size（不需上傳時為 8M，需要上傳時為 32M），以及容器或 cgroup 的記憶體上限。不要使用 RLIMIT_AS 或 RLIMIT_DATA，因為它們可能觸發漏洞。
• 在網頁伺服器或代理層面，限制請求大小、欄位數量、multipart 分段數量及巢狀深度；若網站從不接受上傳，則封鎖 multipart 請求。

推出前請逐一測試每項變更，因為部分設定會令上傳功能失效。若伺服器無法及時修補或緩解，英國 NCSC 及 WordPress.org 均建議考慮將其下線，或將其置於 VPN 或允許清單之後，只讓已知地址存取。

修補期間減少暴露

以上措施都無法阻止掃描器發送請求。針對新漏洞的大規模利用是自動化的：腳本會掃描整個互聯網尋找 PHP 伺服器，然後逐一發動攻擊。這些掃描器通常運行於寄存及數據中心網絡中租用的伺服器上，或經由 VPN、代理及 Tor 轉發。Amazon 首次發現的攻擊嘗試，正是來自一個匿名化服務。真實訪客極少從數據中心瀏覽網站。

因此，在修補所有系統所需的數天內，你可以多加一層防護：在請求到達 PHP 之前，拒絕來自這些網絡的請求。IPScanner 不會偵測 PHP2Shell，亦不會修復 PHP。它檢查連線的來源，將每位訪客歸入一個類別（真人、已驗證爬蟲、惡意自動化、寄存、Tor、VPN、代理及其他幾類），並封鎖你所選擇的類別。

檢查必須在 PHP 之前執行。PHP2Shell 在 PHP 解析請求時觸發，因此任何在 PHP 內部運行的機制都為時已晚。

WordPress 外掛及 WooCommerce 檢查可在你的表單上阻止虛假註冊、垃圾訊息及盜卡測試，但對 PHP2Shell 而言，它們位於錯誤的層級。若 WordPress 網站只運行於單一 Apache 伺服器、前方沒有任何防護，最快的做法是在其前方加上 Cloudflare 及 Worker 作為閘道。

先使用監察模式，再進行封鎖。 監察模式會記錄每一個判定結果，但不會封鎖任何請求，讓你在作出變更之前，先看清楚誰在存取你的 PHP 端點。數小時後，將寄存、Tor 及惡意自動化設為封鎖。VPN 和代理則需自行判斷：管理後台可以封鎖，公開的網店則需三思。來自爬蟲目錄的已驗證搜尋引擎及 AI 爬蟲一律放行。

封鎖功能需要 Starter 方案。在 Free 方案中，網站只以監察模式運行。新帳戶可獲七天 Starter 功能，無需信用卡，足以涵蓋一個修補期。詳見價格。

請清楚了解其限制：

• 使用家用網絡或住宅代理、而又未被檢查識別的攻擊者，仍然可以到達 PHP。
• 閘道採用失效開放（fail open）設計。若 IPScanner API 回應緩慢或無法連線，請求會被放行，網站因此可保持運作。
• 只有流量經過閘道，閘道才能發揮作用。若你的源伺服器在其公開 IP 上回應請求，掃描器可完全繞過 Cloudflare，因此請設定源伺服器只接受來自 Cloudflare IP 範圍的連線。

若你的網站使用 Cloudflare，亦請保持其受管 WAF 規則開啟。Cloudflare 表示，自 10 月 21 日起，其 PHP2Shell 規則已在所有方案上預設運行。這些規則檢查的是請求本身；IPScanner 檢查的是發送請求的一方。兩者都不能取代修補。

檢查是否已被入侵

若伺服器自 10 月中旬起一直未修補，而且暴露於互聯網，請先作檢查，再處理其他事項。各份安全公告及事故應變人員都指向相同的跡象：

• 針對 .php 路徑的大型或深層巢狀 multipart POST 請求，請求內容經常包含 PHP_SESSION_UPLOAD_PROGRESS
• 錯誤記錄中出現「Allowed memory size exhausted」錯誤，以及 PHP worker 大量崩潰或重新啟動
• 網站根目錄中出現新增或被修改的檔案，以及新的 cron 工作或用戶帳戶
• PHP 或網頁伺服器程序啟動 shell，或建立你無法辨認的對外連線

若懷疑已被入侵，請先隔離伺服器並保存記錄，然後才重新啟動任何程序，之後更換 PHP 可讀取的所有機密資料：數據庫密碼、API 金鑰、session 金鑰。

PHP2Shell 檢查清單

1. 列出你運行的所有 PHP 安裝，先處理面向互聯網的部分，包括控制台、設備及容器。
2. 找出處理網頁請求的版本（phpinfo、網站健康狀態、php-fpm -v），而不只是 php -v。
3. 安裝 8.5.12、8.4.27、8.3.36、8.2.35 或發行版的已修復套件。
4. 重新啟動每一個 PHP-FPM pool、Apache 及 LiteSpeed worker；重新建置並重新部署容器。
5. 若使用 8.1 或更舊的版本，取得供應商的向後移植修補或進行升級；若兩者皆不可行，將網站下線或設定允許清單。
6. 暫時無法修補？套用 PHP 的臨時設定，並限制存取。
7. 在 PHP 前方設置閘道（Cloudflare、Traefik、Caddy、nginx），先監察，再封鎖寄存、Tor 及惡意自動化流量。
8. 將源伺服器鎖定為只接受其前方代理的連線。
9. 搜尋 10 月 17 日以來的記錄，查看是否出現上述跡象。
10. 為任何曾經暴露而又未修補的伺服器更換機密資料。

資料來源：PHP 安全公告、GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp、WordPress.org、Cloudflare、watchTowr FAQ、watchTowr、Help Net Security、SecurityWeek、The Hacker News、CNBC、Imperva、Qualys、Armis、Ubuntu、Debian。