php2shell（CVE-2026-109618 / 109619）无法用 php -v 判断：FPM、Docker 与发行版的版本号为何对不上

如果处理 Web 请求的 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，而是“实际提供 Web 服务的 PHP”和“已安装软件包的版本”。

本文集中说明四处只看版本号就会得出错误结论的地方。所有数字和状态信息均为 2026-10-22 时点，各项的来源列在文末。

截至 2026-10-22 已知的情况

PHP 的公告明确指出“唯一完整的修复方式是更新”。在能够更新之前的缓解措施见本文后半部分。

陷阱 1：php -v 与面向 Web 的 PHP 可能不是同一个

通过 SSH 执行的 php -v 显示的是 CLI 版 PHP 的版本。处理 Web 请求的是 PHP-FPM 进程，或加载到 Apache 中的 mod_php，它们是不同的二进制文件和不同的软件包。如果只为 CLI 安装了新版 PHP、并存安装了多个版本，或者 FPM 池指向了另一个版本，那么即使 php -v 显示的是修复版本，Web 端仍可能是旧版本。

有几种方法可以查看 Web 端的真实版本。

# Debian / Ubuntu 上的 FPM（按版本命名）
php-fpm8.3 -v

# RHEL 系的 FPM
php-fpm -v

# 确认 Apache 是否加载了 mod_php
apachectl -M | grep -i php

最可靠的方法，是让通过 Web 实际运行的 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，并用上述方法再次确认 Web 端的版本。

陷阱 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

# 如果自行构建镜像，先重新 pull 基础镜像再构建
docker compose build --pull

# 正在运行的容器内的版本
docker compose exec app php -r 'echo PHP_VERSION, PHP_EOL;'

请将最后一条命令中的 app 替换为你自己的服务名。每个官方镜像都是以单一的 PHP_VERSION 构建的，因此容器内 CLI 的版本与该容器的 FPM / Apache 版本一致（陷阱 1 针对的是直接安装在主机上的 PHP）。

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 只把修复移植到旧版本（回移，backporting）。php -v 显示的数字仍是旧的，因此如果按“低于 8.3.36 就有漏洞”这样的数字规则判断，会把已修复的系统误判为有漏洞。反过来，也不能仅凭数字就放心。请依据软件包版本和各发行版的安全跟踪页面来判断。

截至 2026-10-22，各跟踪页面列出的已修复软件包（两个 CVE 相同）：

这张表直接说明了为什么仅凭数字不够。Ubuntu 24.04 已修复的 PHP 是以 8.3.6 开头的版本，远低于上游的 8.3.36。RHEL 9 的默认 PHP 保持在 8.0.30 的同时已被修复，尽管上游已不再为 8.0 发布修复。Debian 则已升级到与上游相同的版本号（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 中所述的重启和 Web 端检查。

如果 PHP 不是来自发行版自身的软件包，而是来自第三方软件源，就需要关注该软件源的更新。PHP 的公告指出，由志愿者运营的 rpms.remirepo.net 在披露当天不会有更新，并建议改用发行版软件包或自行构建。

陷阱 4：在虚拟主机和托管环境中，你无法自己升级 PHP

在虚拟主机和托管的 PHP 环境中，替换 PHP 运行时的是服务商。这里同样不能只看数字：如果服务商自行构建 PHP 或回移了修复，版本号可能保持旧值。

你自己可以做三件事。

1. 确认 Web 端的版本。使用陷阱 1 中的临时文件输出 PHP_VERSION 和 PHP_SAPI，然后立即删除。如果控制面板中有 PHP 版本选择项，也请记下你选择的版本。
2. 查看服务商的公告，没有的话就去询问。可以这样问：“CVE-2026-109618 和 CVE-2026-109619 的修复将在何时应用到我所用套餐的哪些 PHP 版本（或是否已应用）？”按 CVE 编号而不是版本号询问，得到的答复才会涵盖回移情况。
3. 如果选择的是已不受支持的版本，请升级。PHP 项目不再为 8.1 及更早版本发布修复，8.2 的支持也将于 2026-12-31 结束。除非服务商已回移修复，否则切换版本是可靠的做法。

各虚拟主机服务商的应对情况（截至 2026-10-22）

在共享虚拟主机上，PHP 运行时通常由服务商更新，许多服务商的公告也称“用户无需任何操作”。用户需要做的有两件事：查看所用服务商的官方公告；如果在控制面板中选择了旧版 PHP，则判断是否要切换到公告推荐的版本（已有修复发布的版本）。

下表仅汇总各服务商官方页面（公告和维护信息）上所写的内容，并对公告措辞做了转述。公告会随进展不断更新，因此请务必在所引用的官方页面上确认实际状态。

对于未能找到或打开官方公告的情况，表中写的是“未能确认”或“未能找到”。这里没有信息，并不意味着该服务商没有采取应对措施。请直接查看所用服务商的公告并联系其支持团队确认。

暂时无法立即更新时的缓解措施

PHP 的公告列出了在更新之前可以减小攻击面的设置。不过，公告本身明确指出这些措施“并不能让你变得安全”。主要措施如下：

• 针对 CVE-2026-109619：在 php.ini、FPM 池或服务器配置中设置 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