PHP 严重漏洞风险提醒：如何排查运行环境并做好安全更新

发布日期：2026 年 10 月 22 日

公开报道关联编号：CVE-2026-109618、CVE-2026-109619

具体漏洞编号、影响范围、利用条件与修复版本，请以 PHP 官方安全公告为准。

近期，公开报道披露 PHP 存在两处严重安全漏洞，涉及 PHP 核心引擎，可能导致远程代码执行。PHP 是许多网站的底层运行环境，常见的 WordPress 博客、商城、论坛和管理后台都可能使用它，因此网站维护者需要尽快核查自己的部署环境。

远程代码执行意味着，在满足漏洞利用条件时，攻击者可能通过远程请求，让服务器执行其构造的恶意代码。 影响可能不止是网页被篡改：攻击者还可能以 PHP 服务进程的权限读取网站源码、数据库连接密码和其他配置凭据，窃取数据、植入后门，甚至进一步访问该服务能够连接的其他系统。

这类风险也容易被忽略：网站程序、主题和插件已经更新，不代表底层 PHP 已经修复。 如果服务器或容器中的 PHP 仍处于受影响状态，应用层更新可能无法消除相关风险。

本文未独立核实上述漏洞编号、技术细节及对应修复版本，不将网络流传的版本清单作为判断依据。实际是否受影响，应以 PHP 官方及所用发行版、托管服务商的安全公告为准。

对于网站维护者，当前应优先查清：PHP 运行在哪里、实际使用什么版本、是否对公网提供服务，以及是否已安装对应安全补丁。

一、哪些网站需要自查？

只要实际使用 PHP，就应纳入排查，包括以下常见场景：

类型	常见示例
CMS／建站系统	WordPress、Drupal、Joomla
电商系统	Magento、PrestaShop、OpenCart、WooCommerce 商城
论坛／Wiki	phpBB、Discuz!、MediaWiki、DokuWiki
框架应用	使用 Laravel、Symfony、ThinkPHP、Yii 等开发的应用
自研服务	网站、管理后台、业务 API、上传服务

这些只是帮助识别 PHP 使用场景的示例，并非已确认受上述漏洞影响的产品清单。是否受影响，应根据实际 PHP 版本、补丁状态和官方公布的利用条件判断，不能用 CMS 或框架版本代替 PHP 版本。

主机、容器和托管环境都需要覆盖。后端只有私网地址，也可能通过网关、反向代理或负载均衡向公网提供服务。

二、如何排查实际运行环境？

1. 确认是否使用 PHP

优先检查部署配置、主机管理面板或网站后台的运行环境信息。使用虚拟主机或托管建站服务的用户，可向服务商确认 PHP 版本和补丁安排。

在提供相应 ps 命令的 Linux 主机上，可以查询相关进程：

bash 复制代码

ps -eo pid=,comm=,args= | grep -Ei '[p]hp|[l]sphp|[a]pache2|[h]ttpd'

Apache 使用 mod_php 时，可能没有独立的 PHP 进程。可以根据实际部署运行 apache2ctl -M 或 apachectl -M 检查加载模块；没有 PHP 模块，也需要继续确认是否将请求转发至 PHP-FPM。自定义实例应使用对应的程序和配置。

2. 区分命令行版本和网站运行版本

先查询命令行环境：

bash 复制代码

command -v php
php -v

这里显示的是 CLI 版本，可能与网站实际使用的 PHP 不同。 一台服务器可能同时安装多个 PHP 版本，网站也可能使用容器或独立安装目录中的程序。

对于 PHP-FPM，可以先找到实际进程，再定位其可执行文件。将下面的 12345 替换为实际 PID：

bash 复制代码

php_service_pid=12345
readlink "/proc/${php_service_pid}/exe"

确认程序类型和路径后，使用对应程序查询版本：

bash 复制代码

# 替换为实际 PHP-FPM 路径
/实际路径/php-fpm -v

如果使用 Apache/mod_php，应核对实际加载模块及对应软件包版本。

发行版可能通过安全回补修复漏洞，因此还要检查软件包完整修订号和发行版安全公告，不能只看 PHP 的上游版本号。若进程路径带有 (deleted)，需进一步检查是否仍在运行更新前的旧程序。

3. 检查容器和所有副本

Docker 环境可先查看运行实例：

bash 复制代码

docker ps --format 'table {{.ID}}\t{{.Names}}\t{{.Image}}'

再查询对应容器，将容器名替换为实际名称：

bash 复制代码

docker exec 容器名 php -v

Kubernetes 环境应先确认操作上下文，再查询目标容器。命名空间、Pod 名称和容器名均需替换：

bash 复制代码

kubectl config current-context
kubectl exec -n 命名空间 Pod名称 -c 容器名 -- php -v

上述命令仍然查询 CLI 版本。对于 FPM 容器，需要改为核对实际 FPM 程序，并覆盖不同镜像、部署和运行副本。

镜像标签不能代替运行环境验证，镜像更新也不代表已有容器已经替换。

4. 核对 Web 实际配置

通过已有的受控诊断方式，检查 Web 使用的主配置、附加配置文件，以及 FPM pool 和站点覆盖项。

CLI 的 php --ini、php -i 结果不能直接代表 Web 环境。不要为了排查而在公网新建 phpinfo() 页面，以免泄露环境信息。

5. 确认暴露面并记录结果

结合域名解析、网关、反向代理和负载均衡配置，确认哪些入口最终会将请求交给 PHP 处理。

建议记录站点名称、主机或容器位置、公网入口、实际 PHP 版本、安装来源和补丁状态。信息不足时标记为"待确认"，继续向维护人员或服务商核实。

以上命令用于收集环境信息，并不是漏洞检测工具。无输出、权限不足或命令不存在，都不能据此排除风险。

三、如何更新和临时缓解？

1. 优先安装明确修复漏洞的安全更新

对照 PHP 官方网站的安全公告、版本发布说明，以及所用发行版或托管服务商的安全通知，确认受影响范围和修复方案。

发行版软件包安装： 安装发行版提供的对应安全更新，并核对软件包修订号。
官方源码或独立安装包： 升级至官方明确修复相关漏洞的版本。
容器部署： 更新基础镜像，重新构建并替换运行实例。
虚拟主机或托管服务： 向服务商确认补丁状态、生效时间，以及是否需要调整 PHP 版本。

升级前检查扩展、框架和业务兼容性，做好备份与回退准备。升级后确认所有运行实例和服务进程已更新，并验证登录、支付、上传、后台任务等关键功能。

对于已停止安全维护的 PHP 分支，应优先迁移至受支持版本；使用厂商延长支持的环境，则需确认厂商是否提供了对应安全回补。可通过 PHP 支持版本页面核对分支维护状态。

2. 无法立即升级时，先减少可访问入口

关闭不必要的公网入口，将管理后台和内部服务限制到必要的可信来源，并确保访问限制在请求到达 PHP 之前生效。

持续关注官方公布的利用条件和缓解措施。应用层登录校验不能直接视为对底层 PHP 漏洞的有效防护。

对于网络上流传的关闭 session.upload_progress.enabled 等建议，只有在官方或可信维护方确认适用条件后，才能作为相应的临时措施。不能仅凭关闭某个配置项，就认定两个漏洞均已得到修复。

请勿在生产环境运行来源不明的"PHP2Shell"或其他利用脚本进行自查。

四、更新完成后，如何确认真正生效？

安装更新只是修复过程中的一步，还需要确认实际提供服务的环境已经切换到修复后的程序：

所有相关主机、容器和运行副本均已完成更新。
服务已按部署要求重启或替换，不再运行更新前的旧进程。
核对的是网站实际使用的 PHP，而不只是命令行环境。
发行版或服务商提供的安全回补已明确覆盖相关漏洞。
登录、支付、上传、接口和后台任务等关键功能验证通过。

维护多个站点时，建议为每个站点保留版本、补丁状态和验证结果，避免遗漏旧实例。

对于个人站长，最先要做的三件事是：查清网站实际使用的 PHP 版本，确认服务商或软件源的安全更新，并在更新后验证运行环境与网站功能。

参考入口

PHP 官方网站与发布信息
PHP 当前支持版本
所用 Linux 发行版、容器镜像维护方或托管服务商的安全公告

本文提供环境排查和更新建议，不替代针对具体漏洞的官方公告。请根据后续公开信息及时核对漏洞编号、影响范围、利用条件和修复版本。