PHP2Shell 解讀：兩項嚴重 PHP 漏洞對伺服器的影響

本文由 AI 寫作程式協助撰寫，並由作者編輯。

如果你有任何服務使用 PHP，過去幾週的相關消息可謂紛紜。10 月 21 日，PHP 專案發布緊急修補程式，修復兩個嚴重漏洞，兩者被稱為 PHP2Shell。各方反應則在「這是網絡版 Log4Shell」和「別緊張，公開的漏洞利用程式碼根本無法運作」之間搖擺。兩種説法都有道理。

我是 Adnan Shakir，杜拜網頁代理公司 Grafdom 的技術開發主管。本文嘗試分清哪些已獲證實、哪些只是炒作，解釋這些漏洞的實際運作方式，並提供一些可在自己的伺服器上實際執行的檢查方法。以下內容截至 2026 年 11 月 4 日均為準確資訊，文末附有資料來源連結。

重點摘要

PHP2Shell 是 PHP 本身的兩個漏洞，分別是 CVE-2026-109618 和 CVE-2026-109619。兩者的評分均為 9.2（CVSS v4.0），並可能讓未經驗證的攻擊者遠端執行程式碼（RCE）。
修復版本為 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35，於 2026 年 10 月 21 日發布。PHP 8.1 及更舊版本不會獲得官方版本更新，不過 PHP 團隊已發布適用於 7.4、8.0 和 8.1 的最低限度原始碼回補。
問題出在執行環境。更新 WordPress、外掛或佈景主題都無法修復問題。WordPress.org 表示，無須亦無計劃發布 WordPress 更新。
漏洞確實遭到利用：CISA 於 10 月 26 日將兩個 CVE 加入其已知遭利用漏洞（KEV）目錄。不過，要將這些漏洞轉化為針對隨機公開網站的可靠攻擊並不容易，而且網上流傳的許多概念驗證程式碼都無法運作。
只有套用修補程式才能修復問題。設定旗標和 WAF 規則只能作權宜之計。
在阿聯酋，Censys 於 10 月 25 日標示有 4,691 部面向互聯網的主機可能受影響。

簡短時間線

10 月 17 日：Amazon 的蜜罐記錄到首次漏洞利用嘗試，比公開披露早四天。
10 月 20 日：CVE 編號在網上洩漏，附帶錯誤的發布日期和被誇大的嚴重程度評分。PHP 宣佈將發布緊急更新。
10 月 21 日：Cloudflare 回報早期攻擊（07:43 UTC）。PHP 發布 8.5.12、8.4.27、8.3.36 和 8.2.35。來自 Calif、Wiz 和 OpenAI 的研究人員公開披露漏洞。
10 月 24 日：Perplexity 的 Adel Karimi 回報首次確認在蜜罐伺服器上成功執行程式碼。
10 月 26 日：CISA 將兩個 CVE 加入 KEV 目錄。五天前，CISA 曾表示尚未發現漏洞遭到利用。
10 月 27 日：TU Delft 的威脅情報實驗室回報，來自 70 個國家、600 多個 IP 位址的攻擊者發出超過 50,000 次漏洞利用請求。
自 10 月 29 日起：Palo Alto Networks 警告，面向互聯網的 PAN-OS 管理介面正遭到積極利用。新加坡網絡安全局（CSA）於 11 月 3 日發布公告。

以淺白技術語言解釋這兩個漏洞

以下是 Datadog 的分析文章中根本原因分析的簡化版本，值得閲讀全文。

CVE-2026-109618：記憶體不足時造成的記憶體損毀。PHP 會在你的任何程式碼執行前解析傳入的請求。建立 $_POST 陣列時，PHP 會先增加雜湊表的元素計數器，然後才配置新的鍵值。如果配置所需的記憶體超出 memory_limit，PHP 便會觸發致命錯誤，並留下已計入元素數量、卻從未初始化的資料桶。請求結束時，PHP 會銷毀該陣列，並信任這個資料桶。若堆積記憶體中恰好留有合適的位元組，攻擊者就能將它變成偽造陣列，並使其解構函式回呼指向類似 system() 的位置。

攻擊者面對的難題是：必須調整欄位名稱的長度，令記憶體限制恰好在正確時機被突破、整理堆積區，並繞過 ASLR。Wiz 描述了一種利用 PHPSESSID Cookie 洩漏位址的記憶體披露技巧。

CVE-2026-109619：請求之間的狀態殘留。部分工作程序共用的欄位指向只屬於單一請求的記憶體。如果釋放該記憶體時沒有清除指標（例如致命錯誤中斷重設，或延後執行的診斷功能在清理後重新建立狀態），同一工作程序處理的下一個請求便可能跟隨過期指標。這就是釋放後使用（use-after-free）問題。研究人員確認了兩種觸發途徑：

致命錯誤回溯（僅限 PHP 8.5），已在 mod_php 上確認。
上載處理，已在 mod_php 和 PHP-FPM 上確認。在 FPM 上，應用程式亦必須在啟動後執行合適的操作。

工作階段上載進度預設為啟用，即使應用程式從未呼叫 session_start()，它仍會執行，因此 session.upload_progress.enabled 在緩解建議中不斷出現。此漏洞亦要求攻擊者的請求由同一個工作程序處理，因此增加工作程序池的規模會降低每次嘗試成功的機會，但無法消除漏洞。

問題為何嚴重。有漏洞的程式碼在應用程式執行之前運作。身份驗證、nonce 和自訂安全加固措施都無法發揮作用。即使是安全限制嚴格的自訂應用程式，只要執行相同的 PHP，暴露風險便與使用預設設定的 WordPress 安裝完全相同。

這可能不是最後一次。作者指出，根本原因是一種模式：記憶體錯誤中斷操作，之後清理程序卻信任尚未完整建立的狀態。他們預期會發現更多個案，包括較舊分支中可能尚未修補的變體。

由 AI 發現。Wiz、Calif 和 OpenAI 的研究人員在發現漏洞時使用了 AI 工具。Wiz 認為，這些漏洞已在程式碼中存在多年，而前沿 AI 模型降低了證明漏洞可被利用的門檻。不論這只是單一事件，還是新常態，修補時限都正在縮短：請記住，Amazon 記錄到首次嘗試的時間，比公開披露早四天。

實際上哪些系統面臨風險

任何處理網頁請求的 PHP 執行環境。PHP 的安全公告列出 PHP-FPM、使用 mod_php 的 Apache、php-cgi、FrankenPHP 和 LiteSpeed。mod_php 的風險評級最高，因為未經身份驗證的請求可在應用程式程式碼執行前觸發漏洞。容器和內置 PHP 解譯器的應用程式亦受影響，而命令列上的 php -v 版本可能與網頁伺服器實際執行的版本不同。
受影響版本可追溯至 PHP 5.4。修正已收錄於 8.2.35、8.3.36、8.4.27 和 8.5.12。PHP 8.1 及更舊版本不會獲得官方版本更新。PHP 團隊為 7.4、8.0 和 8.1 發布了最小幅度的原始碼回移修補；不少供應商亦提供自己的回移修補，有時不會更改版本號碼。
設備及內置 PHP。如果供應商的產品內置 PHP，你可能無法自行安裝修補程式。荷蘭 NCSC 的運作清單截至 10 月 28 日記錄了 757 項產品：144 項已修正、218 項受影響，另有 354 項仍在調查。新加坡 CSA 列出PAN-OS、部分 Cisco 產品、Citrix NetScaler、F5 BIG-IP 和 Siemens RUGGEDCOM 產品為受影響項目。
WordPress、Drupal、Joomla、Magento、Laravel。它們都以 PHP 執行，因此底層執行環境若有漏洞，它們都會受影響。WordPress.org 説得很清楚：不需要、亦沒有計劃推出 WordPress 更新，修正方法是更新 PHP。大型主機服務商迅速採取行動（GoDaddy 於 10 月 21 日為託管式 WordPress 修補，並於 10 月 22 日為一般網頁寄存服務修補），但GoDaddy 亦提醒，修補後 PHP 版本號碼可能不會改變。請向主機服務商確認，而不要只看版本號。

漏洞是否真的正被利用？是，但情況不像新聞標題所説

已確認的事項

修補程式推出前，攻擊已經開始。Amazon 的蜜罐於 10 月 17 日記錄到首次攻擊，而 Cloudflare 在 10 月 21 日、修補程式推出前數小時，報告了早期攻擊。
已出現可行的漏洞利用。Perplexity 的 Adel Karimi 於 10 月 24 日報告，在蜜罐上觀察到程式碼執行。他的發現與 CVE-2026-109618 相符，沒有證據顯示當中涉及第二個漏洞。CISA 隨後於 10 月 26 日將兩個 CVE 都加入 KEV。
攻擊量很大。TU Delft 團隊統計到，來自 70 個國家、600 多個 IP 位址的漏洞利用請求超過 50,000 次。
真實產品正受攻擊。Palo Alto Networks 警告，暴露於互聯網的 PAN-OS 管理介面正遭受活躍攻擊。Dream Research 報告了一宗攻擊行動：攻擊者將 PHP2Shell 與 Linux 核心權限提升漏洞（CVE-2026-46300）串連使用，在美國、日本、台灣和南韓的 25 部伺服器取得 root 權限。請留意這個攻擊鏈：PHP2Shell 是入口，核心漏洞則是第二步。

證據較弱的部分

Unit 42 撤回了先前的報道。10 月 23 日，該機構報告指一間歐洲政府機構遭受 AI 代理協助的入侵。10 月 25 日，該機構撤回了這項説法，表示無法確認初始入侵是否與 PHP2Shell 有關。
「AI 驅動的攻擊」目前仍未獲證實。Dream 在攻擊者的基礎設施中發現了 AI 工具，但表示沒有直接證據顯示 AI 編寫了漏洞利用程式。
殭屍網絡攻擊嘗試。截至 10 月 23 日，Sophos 曾觀察到有人透過 PHP2Shell嘗試安裝源自 Mirai 的殭屍網絡，但全部都不成功。

實際情況

Sansec於 10 月 22 日表示，大規模漏洞利用似乎沒有原先擔心的那麼可能，因為攻擊需要掌握目標伺服器的特定資訊，而公開的漏洞利用程式無法在預設 PHP 安裝環境中運作。
Intigriti於 11 月 2 日報告，在 24 個漏洞賞金計劃中，該公司收到 37 宗 PHP2Shell 報告，接納了 3 宗；而所有獲接納的報告都沒有提供可行的概念驗證，證明能夠執行遠端程式碼（RCE）或存取敏感資料。該公司亦指出，許多公開的 GitHub 概念驗證都是由 AI 生成或虛假的。（Intigriti 有銷售偵察工具，因此請審慎看待其説法，但這些數字是該公司提供的。）

我的結論是：安裝修補程式，不必恐慌。「難以可靠地利用」不等於「安全」，而列入 KEV 就代表有人正在利用這個漏洞。

阿聯酋的情況

截至25 October，Censys 統計出阿聯酋有 4,691 部面向互聯網的主機可能受到影響，佔可識別 PHP 版本的該國主機總數 79.5%（Khaleej Times）。這應視為上限，而非實際數量。Censys 根據偵測到的版本號推斷主機是否受影響，因此，透過供應商回移修補程式的主機（版本號沒有改變）可能會被誤判為有漏洞；隱藏版本號的主機則不會計入。全球方面，Censys 數據顯示，在漏洞披露約一星期後，仍有約 3,250 萬項服務使用有漏洞的版本，同樣受上述限制影響。

本地託管服務供應商和企業正套用修補程式，並建議客戶檢查執行環境；Tenable 則將 PHP2Shell 列入最高級別的「值得關注漏洞」層級。

如何檢查自己的技術堆疊

以下是我會在任何 PHP 伺服器上進行的快速檢查。請按你的發行版調整套件名稱。

# Which PHP is the web server really running? (the CLI can differ)
php -v
php-fpm -v                      # PHP-FPM; binary name varies, e.g. php-fpm8.3
apachectl -M | grep -i php      # is mod_php loaded? (apache2ctl on Debian/Ubuntu)

# Vendor backports: the version number alone may not tell you
apt changelog <php-package> | grep -E "CVE-2026-10961[89]"        # Debian/Ubuntu
rpm -q --changelog <php-package> | grep -E "CVE-2026-10961[89]"   # RHEL family

如果你的發行版更新日誌沒有列出 CVE ID，請查閲供應商的安全公告，不要單憑版本字串猜測。

重新啟動或替換所有仍在執行舊程式碼的工作程序。只安裝套件並不足夠；如果 PHP-FPM 或 Apache 仍在記憶體中執行舊的二進制檔，就必須處理。
容器：以已修補的基礎映像檔重新建置映像檔，然後重新部署。不要只重新啟動舊容器。
內置直譯器和開發堆疊（XAMPP、Laravel Herd 等），以及供應商提供的設備：請查閲各供應商的公告。
搜尋被遺忘的伺服器：舊的預備環境網站、已棄用的子網域，以及有人兩年前説「只開一星期」而啟動的測試容器。
仍在使用 PHP 8.1 或更舊版本？取得供應商回移修補的版本（例如 CloudLinux 已為較舊分支發布修補版本），或把升級列入日程。

等待修補程式期間，哪些措施有用、哪些沒有

PHP 團隊表示，沒有任何緩解措施能完全阻擋這些漏洞。請把以下清單視為權宜之計，並留意其中的取捨。

session.upload_progress.enabled=0可緩解 CVE-2026-109619 的上傳途徑。PHP 團隊建議修補後仍將其關閉，除非你的應用程式需要此功能。
fatal_error_backtraces=0（僅適用於 PHP 8.5）可阻擋 CVE-2026-109619 的回溯追蹤途徑。它必須在解析請求前載入，而且需要重新啟動工作程序。
memory_limit=-1可阻擋 CVE-2026-109618 已知的攻擊途徑，但無法消除記憶體配置失敗的風險，也可能讓失控的指令碼耗盡記憶體。如果採用這個方法，請同時在代理伺服器設定請求大小限制，並在容器層級設定記憶體限制。
不要使用 RLIMIT_AS 或 RLIMIT_DATA。它們可能觸發漏洞所依賴的記憶體配置失敗。
WAF 或反向代理可以在請求到達有漏洞的解析器前將其阻擋，但請確認它能看到完整本文、每個欄位和分塊資料。Cloudflare 在漏洞披露前已推出相關規則。這只能提供部分保護，並非修補方案。
隱藏錯誤訊息無濟於事，過時狀態仍然存在。

如何從日誌中發現異常

沒有任何單一訊號足以定論，因此要比對請求、日誌和程序（依循 Datadog 的偵測指引）。

請求：在一般不會使用 PHPSESSID 或 PHP_SESSION_UPLOAD_PROGRESS 欄位的路徑上，出現含有這些欄位的多部分 POST 請求；每個請求的部分數量異常多，或方括號巢狀層數很深（例如機器產生的名稱 files[R00001][a][a][a]）；URL 編碼的本文中，單一欄位名稱長達數 MB；上傳宣告了很大的 Content-Length，然後停滯；Set-Cookie: PHPSESSID= 的值異常冗長、經百分號編碼或為二進制資料。
錯誤記錄：「Allowed memory size ... exhausted」及 Unknown on line 0（故障在請求初始化期間、任何指令碼執行前發生）、Apache AH00052 ... Segmentation fault (11)，或同一個工作程序短時間內連續出現兩至四次記憶體耗盡錯誤，之後便沒有動靜。
程序（最有力的證據）：網頁工作程序（例如 apache2）以 www-data 身分執行，並啟動 sh、bash、下載工具或偵察命令，之後出現對外連線。先記錄網頁用戶平常會執行哪些程序，方便識別異常。
不要單靠狀態碼或程式崩潰判斷。成功的攻擊可以回傳 HTTP 200，並讓工作程序繼續運作。

# Starting points (adjust log paths for your setup)
grep -E "Allowed memory size .* exhausted.*Unknown on line 0" /var/log/apache2/error.log
grep -E "AH00052.*Segmentation fault" /var/log/apache2/error.log

修補可以堵塞漏洞，但無法移除攻擊者已植入的任何內容。因此，如果你的伺服器在 10 月 17 日至修補日期期間曾暴露於風險之中，請檢視這段期間。

修補之外：我會作出的改動

建立資產清單。找不到的項目就無法修補。列出每個 PHP 執行環境（網頁伺服器、容器、隨附版本、測試環境），並記錄其負責人、版本及更新方式。
留意停止支援日期。根據 Patchstack，PHP 8.2 只會獲得安全性修補至 31 December 2026，而 PHP 8.3 則至 31 December 2027，因此應以 8.4 或 8.5 為目標。
為更短的修補時限作好準備。首次嘗試發生在漏洞披露前四日。每月一次的修補週期不足以應付。
限制影響範圍。這些措施都不能取代修補，但應以權限受限的用戶執行 PHP、限制網頁用戶可執行的項目、限制網頁伺服器的對外連線，並在網頁工作程序啟動 Shell 時發出警示。
如無法排除資料曾暴露，請輪換密鑰。其中一個漏洞亦可能洩漏程序記憶體，當中可能存有登入憑證及 API 金鑰。如無法確定資料安全，請輪換資料庫密碼、API 金鑰及工作階段密鑰。

我們在 Grafdom 採取的措施

修補程式推出後，我們已更新並檢查迪拜及阿布扎比十多個客戶網站。

如果你的伺服器也需要同樣的檢查，我們的團隊可以提供協助：grafdom.com。

常見問題

甚麼是 PHP2Shell？這是兩個嚴重 PHP 漏洞 CVE-2026-109618 和 CVE-2026-109619 的俗稱，可能導致未經驗證的遠端程式碼執行。PHP 於 21 October 2026 發佈修補程式。

WordPress 會受 PHP2Shell 影響嗎？間接受影響。WordPress 使用 PHP，因此在有漏洞的 PHP 執行環境上運作的 WordPress 網站會暴露於風險之中。漏洞不在 WordPress 本身，亦不會推出 WordPress 更新。解決方法是更新伺服器上的 PHP。

更新 WordPress、外掛或佈景主題可以修復漏洞嗎？不可以。存在漏洞的程式碼在 PHP 內執行，位於應用程式層之下。

哪些 PHP 版本已修復漏洞？PHP 8.5.12、8.4.27、8.3.36 和 8.2.35，或包含該修補程式的供應商回移植版本。

PHP 7.4 和 8.1 會受影響嗎？會。受影響版本可追溯至 PHP 5.4。8.1 及更舊版本沒有官方版本，但 PHP 已為 7.4、8.0 和 8.1 發佈最小幅度的原始碼回移植修補程式，部分供應商亦有自行提供修補版本。

WordPress 安全外掛可以保護我嗎？無法防範這個漏洞。漏洞會在 PHP 剖析請求時觸發，早於外掛程式碼執行。在伺服器前方部署的 WAF 可以封鎖已知攻擊模式，但 PHP 團隊表示，沒有任何緩解措施可以完全封鎖這些漏洞。

PHP2Shell 是否已在實際環境中遭到利用？是。CISA 將兩個 CVE 均列為已知遭利用漏洞，而研究人員已確認蜜罐上出現程式碼執行，暴露於網絡的 PAN-OS 管理介面亦遭到攻擊。要可靠地利用任意網站，難度遠高於新聞標題中的數字所暗示。

我的阿聯酋網站有風險嗎？如果網站使用 PHP，真正需要確認的是底層執行環境是否已安裝修補程式。Censys 於 10 月 25 日標記阿聯酋有 4,691 台主機可能暴露於風險之中，不過這個數字可能包括已透過回移植修補程式修補的主機。

我應否將網站下線？美國國家安全局（NSA）建議機構在無法立即修正漏洞時，將受影響的網站下線。Sansec 於 10 月 22 日的看法是，一般網店毋須下線，但仍應更新。我認為：如果今天可以修補，就立即修補。如果無法修補（例如使用已終止支援的 PHP，或供應商提供的設備），就透過 WAF 或 VPN 限制暴露，或先將網站下線，直至可以修補為止。

我怎樣知道自己是否遭入侵？檢查由 10 月 17 日起的記錄，首次攻擊嘗試於當日被記錄。留意不熟悉的管理員帳戶、並非由你新增的新檔案，以及啟動 Shell 的網頁程序。修補程式不會移除早前植入的任何內容。

Python 網站又如何？PHP2Shell 隻影響 PHP，Python 應用程式不受影響。另一宗無關的供應鏈攻擊於 10 月 21 日影響 LiteLLM Python 套件（PyPI 上的 1.107.0 版本曾遭入侵，持續約兩小時）。

關於作者

Adnan Shakir 是 Grafdom 的技術開發主管。Grafdom 是一家屢獲殊榮的數碼媒體代理機構，位於阿聯酋杜拜。Grafdom 於 2005 年成立，為杜拜和阿布扎比的企業機構、跨國公司及政府部門設計、開發和維護網站。憑藉二十年的專業經驗，Grafdom 已成為中東各地高層管理團隊信賴的技術合作夥伴及顧問。Grafdom 已建立聲譽，成為海灣地區最大型地產公司、教育機構及銀行業企業首選的代理機構。