php2shell（CVE-2026-109618 / 109619）無法用 php -v 判斷：FPM、Docker 與各發行版的版本號會在哪裡對不上

如果實際處理網頁請求的 PHP（PHP-FPM、Apache 的 mod_php、php-cgi、FrankenPHP、LiteSpeed）版本早於 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12，就會受到俗稱 php2shell 的 CVE-2026-109618 與 CVE-2026-109619 影響。修正方式是升級到上述版本（若是發行版套件，則升級到已修正的套件）並重新啟動相關程序。需要確認的不是你本機的 php -v，而是「實際提供網頁服務的 PHP」與「已安裝的套件版本」。

本文聚焦於四個「只看版本號就會得出錯誤結論」的地方。所有數字與狀況皆為 截至 2026-10-22 的資訊，各項目的出處列於文末。

截至 2026-10-22 已知的資訊

PHP 的公告指出「唯一完整的修正方式就是更新」。在能夠更新之前的緩解措施，會在本文後半說明。

陷阱 1：php -v 與網頁端的 PHP 可能是不同的東西

透過 SSH 輸入的 php -v 顯示的是 CLI 版 PHP 的版本。處理網頁請求的是 PHP-FPM 程序，或載入 Apache 的 mod_php，這些是不同的執行檔、不同的套件。如果只為 CLI 安裝了較新的 PHP、並存安裝多個版本，或 FPM 的 pool 指向另一個版本，即使 php -v 顯示的是已修正版本，網頁端仍可能是舊版。

要查看網頁端的實際版本，有幾種方法。

# Debian / Ubuntu 的 FPM（名稱依版本而異）
php-fpm8.3 -v

# RHEL 系列的 FPM
php-fpm -v

# 確認 Apache 是否載入了 mod_php
apachectl -M | grep -i php

最可靠的方法，是讓實際透過網頁執行的 PHP 自己回報版本。暫時放置一個不易被猜到名稱的檔案，確認完畢後立刻刪除。

<?php echo PHP_VERSION, ' ', PHP_SAPI;

如果 PHP_SAPI 是 fpm-fcgi，表示 PHP 以 FPM 執行；apache2handler 表示 mod_php；cgi-fcgi 表示 CGI。請避免讓 phpinfo() 持續公開，因為這本身就會洩漏資訊。

重新啟動也是容易漏掉的一步。即使套件已經被替換，已在執行的 php-fpm 或 Apache 程序仍可能繼續執行舊的程式碼。有些環境會在套件更新時自動重新啟動，有些則不會。更新後請重新啟動 FPM / Apache，並用上述方法再次確認網頁端的版本。

陷阱 2：使用 Docker 時，不能只看標籤名稱

官方的 php 映像檔有內容會被替換的「浮動標籤」，例如 8.3 與 8.3-fpm，也有固定版本的標籤，例如 8.3.30。

• 浮動標籤即使在 Docker Hub 上已換成已修正版本，在你重新 pull 之前，本機仍是舊的映像檔。執行中的容器在重建之前，也會繼續使用舊映像檔。Dockerfile 中的 FROM php:8.3-fpm，如果建置快取中還留有舊的基底，建置出來的仍會是舊版。
• 固定標籤在你自己調高版本號之前，會永遠維持舊版。

已修正版本的標籤是否已發布，可以用 Docker Hub 的 API 確認。

curl -s "https://hub.docker.com/v2/repositories/library/php/tags?name=8.3.36&page_size=100"

以下是 2026-10-22 針對四個版本系列查詢的結果（時間為 UTC）。

這次查證發現，僅憑版本數字判斷容易誤判的地方有三點。

1. 「最近更新過」不等於「已修正」。固定標籤 8.3.35 在 2026-10-21 當天曾被重新建置，但其中的 PHP_VERSION 仍是 8.3.35。請看映像檔內部的版本，而不是更新時間。
2. digest 不同，內容也可能相同。8.3 與 8.3.36 的標籤 digest（多架構索引的值）不同，但 amd64 映像檔是同一個，兩者的 PHP_VERSION 都是 8.3.36。8.3-fpm／8.3.36-fpm、8.4-apache／8.4.27-apache、latest／8.5.12、8.5-fpm、8.2-fpm 也一樣，amd64 映像檔的 PHP_VERSION 都是修正版。
3. 8.1 及更早版本沒有已修正的官方映像檔。8.1-fpm 的最後更新日是 2025-12-31。

檢查本機映像檔與執行中的容器，可以這樣做：

# 本機已 pull 的映像檔之 PHP 版本
docker image inspect php:8.3-fpm --format '{{range .Config.Env}}{{println .}}{{end}}' | grep PHP_VERSION

# 重新 pull，並重建容器
docker compose pull
docker compose up -d

# 若自行建置映像檔，請先重新取得基底映像檔再建置
docker compose build --pull

# 執行中容器內的版本
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

請將最後一個指令中的 app 換成你自己的服務名稱。官方映像檔每個映像檔只以單一 PHP_VERSION 建置，因此容器內 CLI 的版本會與該容器的 FPM／Apache 版本相同（陷阱 1 指的是直接安裝在主機上的情況）。

FrankenPHP 內嵌了 PHP，因此 FrankenPHP 本身的版本與內嵌 PHP 的版本是不同的數字。2026-10-21 發布的 FrankenPHP 1.13.2 版本說明寫道：Docker 映像檔以 PHP 8.2.35／8.3.36／8.4.27／8.5.12 建置，靜態二進位檔則以 PHP 8.5.12 建置。

陷阱 3：發行版套件是「版本號維持舊的，但已修正」

Ubuntu 與 RHEL 只將修正內容移植到舊版本（backport，向後移植）。php -v 顯示的數字仍是舊的，所以若用數字判斷「低於 8.3.36，因此有風險」，已修正的系統也會被判為有風險。反過來，也不能只看數字就放心。請依套件版本與各發行版的安全追蹤頁面來判斷。

截至 2026-10-22，各追蹤頁面列出的已修正套件（兩個 CVE 相同）：

這張表直接說明了為什麼只看數字不夠。Ubuntu 24.04 已修正的 PHP 是以 8.3.6 開頭的版本，遠低於 upstream 的 8.3.36。RHEL 9 的預設 PHP 維持 8.0.30 即已修正，儘管 upstream 已不再為 8.0 發布修正。Debian 則已升到與 upstream 相同的版本號（8.2.35／8.4.27）。

也有些套件尚未修正（截至 2026-10-22）。

• RHEL 9 的 php 模組 8.4 被列為「受影響，尚無修正」。
• Debian forky（testing）的 php8.4 為 8.4.26-1，標示為「vulnerable」。sid（unstable）的 php8.4 為 8.4.27-1，已修正。

在自己的伺服器上檢查的指令範例：

# Debian / Ubuntu：已安裝的版本與可取得的版本
apt-cache policy php8.3-fpm libapache2-mod-php8.3

# Ubuntu：此伺服器上是否已修正這個 CVE
pro fix CVE-2026-109618
pro fix CVE-2026-109619

# RHEL 系列：是否有修正此 CVE 的更新，以及已安裝的版本
dnf updateinfo list --cve CVE-2026-109618
rpm -q php-fpm php-cli

請依你的環境調整套件名稱（php8.3-fpm 等）。將顯示的版本與上表或追蹤頁面中的「已修正版本」比較，若相同或更高，即表示已含修正。接著請完成陷阱 1 所述的重新啟動與網頁端確認。

若你不是使用發行版本身的套件，而是從第三方儲存庫安裝 PHP，就必須自行追蹤該儲存庫的更新。PHP 的公告指出，由志工維運的 rpms.remirepo.net 在公開當天不會有更新，並建議改用發行版套件或自行建置。

陷阱 4：共享主機與託管環境無法自行升級 PHP

在共用主機與託管式 PHP 環境中,PHP 執行環境是由服務供應商負責替換。這裡同樣不能只看版本號:如果供應商自行編譯 PHP,或將修補程式回移(backport)到舊版本,版本號可能仍然維持舊的數字。

您自己可以做的有三件事。

1. 確認 Web 端的版本。使用陷阱 1 的暫時檔案印出 PHP_VERSION 與 PHP_SAPI,然後立即刪除。如果控制台有選擇 PHP 版本的功能,也請記下目前選用的版本。
2. 閱讀供應商的公告,若沒有就去詢問。可以這樣問:「CVE-2026-109618 與 CVE-2026-109619 的修正,會套用到我所用方案的哪些 PHP 版本、何時套用(或是否已套用)?」以 CVE 編號而非版本號詢問,得到的回覆會連回移修正(backport)的情況一併涵蓋。
3. 若選用的是已終止支援的版本,請升級。PHP 專案不會為 8.1 及更早版本發布修正,8.2 的支援也將於 2026-12-31 結束。除非供應商已回移修正,否則切換版本才是可靠的做法。

各主機服務商的處理狀況(截至 2026-10-22)

在共用主機上,PHP 執行環境通常由服務商更新,許多業者的公告也表示「使用者無須進行任何操作」。使用者要做的有兩件事:確認所使用服務商的官方公告;若在控制台中選用了舊版 PHP,則評估是否要切換到公告所建議的版本(已有修正版的版本)。

下表僅整理各服務商官方頁面(公告與維護資訊)上所載的內容,並以意譯方式摘要公告的措辭。公告會隨處理進度更新,實際狀況請務必以所列出處的官方頁面為準。

對於找不到或無法開啟官方公告的服務商,表中寫的是「無法確認」或「找不到」。沒有相關資訊並不代表該服務商尚未處理。請直接向您的服務商查看公告並洽詢客服。

無法立即更新時的緩解措施

PHP 的公告列出了在能夠更新之前可縮小攻擊面的設定。不過公告本身也明確表示這些措施「並不會讓您變得安全」。主要項目如下:

• 針對 CVE-2026-109619:在 php.ini、FPM 的 pool 或伺服器設定中設定 session.upload_progress.enabled=0,並重新啟動所有 worker(ini_set() 與 FPM 的 .user.ini 對此無效)。在 PHP 8.5 上,還需設定 fatal_error_backtraces=0。
• 針對 CVE-2026-109618:以應用程式無法覆寫的方式設定 memory_limit=-1,並調低 post_max_size(沒有上傳功能時設為 8M,有上傳功能時設為 32M)。請勿以 RLIMIT_AS / RLIMIT_DATA 代替。

英國 NCSC 建議,對於無法立即更新或緩解的系統,可考慮將其下線,並在更新或套用緩解措施之前,先檢查是否有遭入侵的跡象。

出處(2026-10-22 確認)

• php.net: Security advisory: Critical remote code execution vulnerabilities, update now (2026-10-21)
• php.net: Upcoming Critical PHP Security Release (2026-10-20)
• php.net: PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 的發布公告
• GitHub: GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• GitHub: GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Docker Hub: 官方 php 映像檔
• FrankenPHP 1.13.2 發行說明
• Debian Security Tracker: CVE-2026-109618 / CVE-2026-109619
• Ubuntu:CVE-2026-109618 / CVE-2026-109619 / USN-8948-1 / USN-8948-2
• Red Hat:CVE-2026-109618 / CVE-2026-109619(已修正套件的版本取自 Red Hat 的 VEX 資料)
• NCSC: Critical security issue affecting PHP