PHP 漏洞：PHP2Shell 修補程式與 PHP 版本確認（WordPress）

測試環境 RHEL 系列AlmaLinux 9.8PHP 8.3 · WordPress 7.1.32026-10-22 確認

PHP2Shell 是 2026 年 10 月 21 日公布修補程式的兩個 PHP 漏洞（CVE-2026-109618 · CVE-2026-109619）的名稱。這是即使沒有登入的請求也能在伺服器上執行程式碼的遠端程式碼執行漏洞，所以第一步是確認你的網站使用的 PHP 版本，並升級到已修補的版本。以下是在執行 WordPress 7.1.3 的 Nginx + Apache 伺服器上，用網站狀態確認 PHP 版本、只把 php 套件升級到已修補版本，再重新確認的過程。

2 分鐘閱讀

1️⃣ PHP 漏洞 PHP2Shell：漏洞原理與影響範圍

這些漏洞位於在 WordPress 程式碼執行前就讀取請求的 PHP 引擎中，所以就算你把外掛和佈景主題保持在最新，只要不升級 PHP，漏洞就會一直存在。依 CERT-EU 的警示，兩個漏洞的 CVSS 分數都是 9.2；技術細節已經公開並引發討論，初期的概念驗證程式碼也開始流傳。

CVE-2026-109618 是請求超過記憶體上限（memory_limit）而中斷時，清理程序會把只初始化一半的請求資料當成正常資料處理的漏洞。CVE-2026-109619 是致命錯誤後被釋放的記憶體狀態殘留下來，在同一個 worker 處理的下一個請求中於初始化前被再次使用的漏洞。

依 php.net 公告，所有處理網頁請求的 PHP 安裝都受影響，其中 Apache mod_php 被視為最危險的組態。因為在 mod_php 上已有示範顯示，一個沒有登入的請求就能在應用程式碼執行前觸發攻擊。

PHP 執行方式	影響	備註
Apache mod_php	🔴 受影響 · 最危險	一個沒有登入的請求就在應用程式碼執行前觸發攻擊的示範
PHP-FPM	🔴 受影響	—
php-cgi	🔴 受影響	—
FrankenPHP	🔴 受影響	—
LiteSpeed	🔴 受影響	—

已修正的版本是 8.2.35、8.3.36、8.4.27 與 8.5.12，比這些更低的 8.2～8.5 系列全部受影響。PHP 8.1 以下是 PHP 專案已停止支援的系列，所以沒有官方修補版本，要靠發行版或主機商移植進去的修正（backport）來因應。

CISA 在 10 月 21 日發布公告時，尚未確認有實際遭到利用的情況，但 CISA 認為放著不修補很危險，建議從暴露在網際網路上的系統開始立即修補。CERT-EU 在同一天的警示中判斷，隨著概念驗證程式碼開始流傳，攻擊者已經在利用這些漏洞的可能性也提高了。

2️⃣ 確認 PHP 版本：網站狀態 › 網站狀態資訊 › 伺服器

就算知道了漏洞，如果不知道自己的網站是用哪個 PHP 版本執行，也無法決定要做什麼。請在管理後台開啟 [工具 › 網站狀態]，在 [網站狀態資訊] 分頁展開 [伺服器] 區塊，[PHP 版本] 這一列就會顯示實際處理網站請求的 PHP 版本。

網站狀態資訊分頁畫面：左側選單工具 › 網站狀態，伺服器區塊的伺服器架構、網頁伺服器軟體、PHP 版本、PHP SAPI 列 — 作為確認 PHP 漏洞 PHP2Shell 修補基準的 PHP 版本（WordPress 7.1.3）

[PHP 版本] 正下方的 [PHP SAPI] 列顯示 PHP 的執行方式，fpm-fcgi 代表 PHP-FPM 組態。這裡只看 [伺服器] 區塊的 [PHP 版本] 與 [PHP SAPI] 兩列。

🧩 PHP2Shell 攻擊流程

說明圖解

①沒有登入的請求任何人都能送出的網頁請求

②特別製作的請求PHP 比 WordPress 程式碼先讀取

③PHP 漏洞記憶體不足 → 直接使用沒做完的資料CVE-2026-109618下一個請求使用已結束請求的狀態CVE-2026-109619

④在伺服器上執行程式碼網站遭到控制

✅ 修正版會擋下這個流程8.2.35 · 8.3.36 · 8.4.27 · 8.5.12

攻擊從一個沒有登入的請求開始。在 PHP 比 WordPress 程式碼先讀取這個特別製作的請求的階段，請求會觸發兩個漏洞之一，進而在伺服器上執行程式碼。修正版會擋下這個流程，所以要做的是把網站的 PHP 升級到修正版或更新的版本。

終端機的 [php -v] 只會顯示命令列預設 PHP 的版本。像 cPanel 的 EA-PHP 或 CloudLinux 的 alt-php 這種在一台伺服器上安裝多個 PHP 版本的組態，它可能和網站使用的版本不同。所以要以網站狀態的 [PHP 版本] 值為準。

php -v

PHP 8.3.xx (cli) (built: Jun  3 2025 17:17:57) (NTS gcc x86_64)

3️⃣ 低於 PHP 8.2 時：向主機商確認是否已套用 backport，沒有就提出要求

如果網站狀態的 [PHP 版本] 低於 8.2（7.x · 8.0 · 8.1），php.net 就沒有官方修補版本。依 php.net 的支援版本表（2026 年 10 月 22 日確認），目前支援的只有 8.2、8.3、8.4、8.5 四個系列，8.1 以下的官方版本不會再推出安全性修補。

不過，發行版或主機商有時會推出版本號維持不變、只移植修正進去的套件（backport）。某家代管型主機測試伺服器上的 7.4.33 · 8.0.30 · 8.1.34 套件就是一例。它們的變更記錄中有一行 [Backported from 8.2.35 — CVE-2026-109618, CVE-2026-109619]。

即使版本號相同，也可以在套件的變更記錄中搜尋 CVE 編號，確認修正是否已包含在內。Debian · Ubuntu 系列可用 [zcat /usr/share/doc/php8.2-cli/changelog.Debian.gz | grep 109618] 這種方式搜尋。RPM 系列則是 [rpm -q --changelog php-common | grep 109618]，套件名稱中的版本號要配合網站使用的版本。

所以如果低於 8.2，請先向主機商確認是否已套用 backport；如果沒有套用或無法確認，就要求升級到支援中的版本（8.2 以上）。升級後再用網站狀態的 [PHP 版本] 值重新確認。

CISA 建議使用 8.1 以下、又無法立即更新的組織，在修補或升級之前讓以 PHP 為基礎的系統保持離線。

如果你自己管理伺服器並使用 8.1 以下，可以安裝發行版的 backport 套件，或套用 PHP 安全團隊針對 7.4 · 8.0 · 8.1 發布的原始碼修補。不過這些仍是已停止支援的系列，根本的做法還是升級到支援中的版本。

4️⃣ PHP 8.2 以上時：更新到已修補版本並重新確認

如果是 8.2 以上但低於修補版本，就升級 PHP 本身。代管型主機和共用主機由業者對整台伺服器套用修補，所以請透過業者公告或詢問客服確認是否已套用、使用的是哪個建置版本，再看網站狀態的 [PHP 版本] 是否改變。依狀態頁面的公告，Cloudways 在 10 月 21 日 22:19 UTC 開始為所有支援的 PHP 版本（5.6～8.4）套用修補，並在 10 月 22 日 10:11 UTC 宣布完成。

🪐參考資料PHP2Shell 2

📡【緊急】70% 網站都在用的 PHP 出現緊急狀況｜漏洞與現在要做的事（韓語） 🌌Cloudways 代管型主機

自己管理的伺服器，依 php.net 公告使用發行版或 LTS 業者套件庫中的套件升級。更新前先用預覽確認會變更的套件清單，確保只有以 php 開頭的套件被升級、沒有其他套件跟著一起更新，也不要和作業系統的其他更新混在一起。

dnf upgrade --assumeno 'php*'

Dependencies resolved.
================================================================================
 Package       Architecture  Version         Repository  Size
================================================================================
Upgrading:
 php           x86_64  8.3.xx-1.…        …       1.9 M
 php-cli       x86_64  8.3.xx-1.…        …       5.6 M
 php-common    x86_64  8.3.xx-1.…        …       1.3 M
 php-fpm       x86_64  8.3.xx-1.…        …       1.9 M
 （省略 php-gd · php-intl 等擴充套件的列）

Transaction Summary
================================================================================
Upgrade  xx Packages

dnf upgrade 'php*'

Upgraded:
  php-8.3.xx-1.….x86_64
  php-cli-8.3.xx-1.….x86_64
  php-common-8.3.xx-1.….x86_64
  php-fpm-8.3.xx-1.….x86_64
  （省略擴充套件的列）

Complete!

這次實測中，只有以 php 開頭的套件升級到修補版本，套件安裝完成時 php-fpm 也自動重新啟動。修正版要在 php-fpm 的 worker 重新啟動後才會生效，所以在沒有自動重新啟動的環境中，請自己執行 [systemctl restart php-fpm]。

升級後，請確認 [php -v] 和網站狀態 [網站狀態資訊] 分頁的 [PHP 版本] 列是否都在修補版本以上，並一併確認 php-fpm 服務狀態與網站回應。如果只有命令列的值改變、[PHP 版本] 的值維持不變，請重新啟動 php-fpm 後再確認一次。

網站狀態資訊分頁畫面：更新後再次確認伺服器區塊的 PHP 版本列在修補版本以上 — 左側選單工具 › 網站狀態，伺服器區塊的 PHP 版本、PHP SAPI 列（WordPress 7.1.3）

更新後也一樣，在同一個 [工具 › 網站狀態] 的 [網站狀態資訊] 分頁展開 [伺服器] 區塊，查看 [PHP 版本] 列。如果這個值已變成升級後的版本，代表 php-fpm 的 worker 也已經用新版本在執行。

php -v

PHP 8.3.xx (cli) (built: Oct 19 2026 14:00:34) (NTS gcc x86_64)

systemctl is-active php-fpm

active

curl -s -o /dev/null -w '%{http_code}\n' 'https://example.com/?r=1'

版本號本身會提高的套件，用新的版本號確認是否已修補；版本號維持不變的 backport 套件，則用變更記錄中的 CVE 編號確認。這次的伺服器屬於前者，所以 [rpm -q --changelog php-common] 中沒有 CVE 編號那一行，是用變更記錄第一行的新版本號確認的。

5️⃣ 無法立即升級時：php.net 說明的暫時措施

針對無法立即升級的伺服器，php.net 說明了下列設定作為暫時措施，同時表明這些措施只能縮小特定的攻擊途徑，無法讓安裝變得安全。它也寫到不要改用 RLIMIT_AS 或 RLIMIT_DATA 設定記憶體上限，因為那樣反而可能引發有漏洞的記憶體配置失敗。

設定	值	設定位置	防範對象
memory_limit	-1	FPM 集區 · Apache 設定中的 php_admin_value（讓應用程式無法改回）	CVE-2026-109618 · 記憶體上限失敗途徑（不完全）
post_max_size	8M（需要上傳時用 32M） · upload_max_filesize 設得比它小	php.ini · 集區設定	CVE-2026-109618
session.upload_progress.enabled	0 + 重新啟動所有 worker	php.ini · FPM 集區 · 伺服器設定（不能用 ini_set() · .user.ini）	CVE-2026-109619 · 僅限已確認的工作階段途徑
fatal_error_backtraces	0 + 重新啟動所有 worker（僅 PHP 8.5）	同上	CVE-2026-109619 · 僅限已確認的回溯追蹤途徑

php_admin_value 是應用程式無法改回的伺服器端設定，所以共用主機的使用者通常無法自己修改，這時最後還是要向主機商提出要求。php.net 也建議在網頁伺服器或代理伺服器層級，對請求本文大小、輸入欄位數、multipart 區段數、標頭數與巢狀深度設定上限。

🔢 FAQ & 推薦內容

WordPress 自動更新只處理核心、外掛、佈景主題與翻譯；PHP 是安裝在伺服器上的程式，要由伺服器管理員或主機商升級。核心、外掛、佈景主題的自動更新，分別在 WordPress 更新畫面與外掛 · 佈景主題畫面中開啟，這些畫面都不會顯示 PHP 版本。

完整的技術細節在 php.net 公告於 CVE 編號旁連結的兩份 GitHub 安全性公告中。CVE-2026-109618 是 GHSA-w8hw-w9fx-j79w，CVE-2026-109619 是 GHSA-6wmf-4rv5-p3rp。CERT-EU 的警示也把同樣這兩份公告列為參考資料，而重現攻擊的細節沒有放進本文。

CISA 建議監控 PHP worker 行程開啟 shell 或下載工具的行為，也提到在修補之前，網頁應用程式防火牆能提供一定程度的保護。由於 PHP 經常作為其他軟體的元件內嵌其中而不易察覺，CISA 建議先從列出執行 PHP 的系統清單開始。

安全性 wp-config.php 安全漏洞防止 wp-config.php 檔案外洩並強化安全性設定的方法。

安全性 WordPress XML-RPC 從記錄判斷 xmlrpc.php 攻擊並停用它的三種方法。

伺服器 php-fpm max_children 警告在增加 worker 之前，先用記錄找出警告原因的實測。

🪐參考資料PHP2Shell 6

📡PHP: Security advisory — Critical remote code execution vulnerabilities, update now (2026-10-21) 📡CISA: Critical Vulnerabilities in PHP Require Immediate Patching (2026-10-21) 📡CERT-EU Security Advisory 2026-018: Critical Vulnerabilities in PHP 📡GitHub 安全性公告 GHSA-w8hw-w9fx-j79w（CVE-2026-109618） 📡GitHub 安全性公告 GHSA-6wmf-4rv5-p3rp（CVE-2026-109619） 🛰️Sansec: PHP2Shell — PHP RCE (CVE-2026-109618, CVE-2026-109619)

ℹ️ 聯盟行銷說明
本站內容包含聯盟行銷連結。訪客透過這些連結購買商品或服務時，本站會從賣家獲得佣金。在這個過程中，購買者支付的金額^{（遇到活動折扣時金額會降低↓）}並不會因此提高。刊登的價格、折扣與庫存資訊以撰寫當時為準，可能與實際情況不同，購買前請向賣家做最後確認。商品的挑選與評價依本站自訂的標準撰寫，是否支付佣金不會影響介紹順序或評價內容。