PHP 炸了！两个 CVSS 9.2 致命漏洞，无需登录就能控制服务器——手把手修复指南

PHP 炸了！两个 CVSS 9.2 致命漏洞，无需登录就能控制服务器——手把手修复指南

2026 年 10 月 21 日，PHP 官方紧急发布安全版本，修复了两个可被未认证攻击者直接远程代码执行（RCE）的致命漏洞（代号 php2shell：CVE-2026-109618 / CVE-2026-109619，CVSS v4.0 均为 9.2）。
全球多国政府网站被迫临时下线，安全机构已监测到在野利用。本文是一份照做就能完成的修复手册：先讲后果，再给步骤，最后附排查清单。

一、这次漏洞有多严重？

一句话：攻击者不需要登录、不需要利用你业务代码里的任何漏洞，只发一个构造过的 HTTP 请求（比如一个超大 multipart POST），就能在服务器上执行任意代码。

严重性体现在四点：

两个漏洞的原理（不用深究也能理解的程度）：

二、先判断你受不受影响（1 分钟）

对照下表：

先查一下版本：

php -v

注意：php -v 只代表 CLI 环境。服务器上往往同时存在多套 PHP（FPM、Apache 模块、容器镜像），要逐个确认，见第三步盘点。

三、修复步骤（照做即可）

第 0 步：备份（10 分钟）

• 备份站点代码、php.ini、FPM 池配置、数据库（mysqldump 或云快照）。
• 留好回滚路径：记录当前版本号；Docker 升级前给旧镜像打个 tag（docker tag 旧镜像 myphp:rollback）。

第 1 步：盘点所有 PHP 实例

# CLI 版本
php -v
php –ini

# 找出所有 PHP 进程 / 服务
ps -ef | grep -E 'php|php-fpm'
systemctl list-units –type=service | grep -i php

# Apache mod_php
httpd -M 2>/dev/null | grep php # 或 apachectl -M

# Nginx 实际转发到哪个 PHP
nginx -T 2>/dev/null | grep -E 'fastcgi_pass|unix:'

# Docker 环境
docker ps | grep -i php
docker exec <容器ID> php -v

整理成清单：实例 / 当前版本 / SAPI / 服务名 / 目标版本。多版本共存时，每个站点实际走的版本以 fastcgi_pass 指向的 socket 为准。

第 2 步：升级到修复版本（按你的环境选一条）

Debian / Ubuntu：

sudo apt update
apt-cache policy php8.4-fpm php8.4-cli # 确认候选版本是 8.4.27+
sudo apt upgrade php8.4-* # 按实际分支替换 8.2/8.3/8.4/8.5

仓库没跟上就用官方 PPA：

sudo add-apt-repository ppa:ondrej/php
sudo apt update && sudo apt upgrade php8.4-*

CentOS / RHEL / AlmaLinux / Rocky：

sudo dnf –enablerepo=remi-php84 update php php-fpm php-* # 按分支替换 remi-php82/83/84/85
php -v

提醒：remi 是志愿者仓库，发布日当天可能没有同步补丁，优先用发行版官方包或源码编译。

Docker：

docker tag <旧镜像> myphp:rollback # 升级前打 tag 留回滚
# 修改 Dockerfile / compose 镜像 tag 为修复版本，如 php:8.4.27-fpm
docker compose pull && docker compose up -d
docker exec <容器ID> php -v

Windows（本机直接跑 PHP）：

宝塔等面板： 软件商店 → PHP 版本管理安装修复版本，或在「网站」里把站点切换到已修复版本并重启；面板没提供就走源码编译。

云托管 / 虚拟主机： 直接联系服务商确认是否已打补丁，无法控制环境就评估迁移或临时下线。

第 3 步：重启所有工作进程（重要：用 restart，别只用 reload）

sudo systemctl restart php8.4-fpm # FPM，按实际服务名
sudo systemctl restart apache2 # mod_php（Debian/Ubuntu）
sudo systemctl restart httpd # mod_php（RHEL 系）
# Docker：docker compose restart 或滚动替换

重启后确认旧 worker 全部退出：ps -ef | grep php，看进程启动时间是否都是新的。reload 不能保证所有旧实例退出，本次要求重启每一个 worker。

第 4 步：验证（在实际 Web 环境，而不是只看 CLI）

四、实在升级不了？临时缓解（只能降风险，不能根治）

官方明确：没有任何配置缓解能完整替代补丁，立即升级是唯一完整修复。 以下措施只降低特定攻击路径的暴露。

FPM 池配置（如 /etc/php/8.4/fpm/pool.d/www.conf）追加：

; 对应 CVE-2026-109618：解除可被利用的 memory_limit 失败（用 php_admin_value 防应用覆盖）
php_admin_value[memory_limit] = -1
; 调低请求体上限：无上传 8M，需上传 32M
php_admin_value[post_max_size] = 8M
php_admin_value[upload_max_filesize] = 8M ; 必须小于 post_max_size
; 对应 CVE-2026-109619：关闭会话上传进度路径
php_admin_value[session.upload_progress.enabled] = 0
; 仅 PHP 8.5：关闭致命错误回溯路径
php_admin_value[fatal_error_backtraces] = 0

Apache mod_php：在 httpd.conf / 虚拟主机用 php_admin_value memory_limit -1 等同等设置。

Web 层：Nginx 设 client_max_body_size 8m，并考虑限制字段数、multipart 数、header 数与嵌套深度（覆盖无 Content-Length 的请求）；容器用 cgroup 内存上限做可用性边界，不要用 RLIMIT_AS / RLIMIT_DATA。

改完必须重启全部 worker。仍然无法修复的对外服务：临时下线或隔离公网，直到补丁应用并验证完成。

五、升级完成后必做：排查是否已被入侵

漏洞已有在野利用，且 PoC 在流传，升级后请按清单排查：

• 访问日志：异常超大的 multipart POST、字段数异常、连续 413/500；PHP 错误日志里的 Allowed memory size exhausted、segfault。
• Web 目录：近期新增/修改的 .php 文件；eval、base64_decode、assert、shell_exec 等可疑特征；上传目录、wp-content/uploads、.user.ini、.htaccess 异常改动。
• 进程与计划任务：ps -ef 可疑进程；crontab -l、/etc/cron* 新增项；ss -tnp 异常外连。
• 系统账号：新增用户、sudoers 改动。

高度怀疑被入侵：立即隔离 → 保留现场取证 → 从干净备份重建 → 轮换所有凭据与密钥。WAF / 云防火墙规则只能纵深防御，不能替代补丁。

六、三个最容易踩的坑

参考资料

• PHP 官方安全公告：https://www.php.net/
• CERT-EU Security Advisory 2026-018：https://cert.europa.eu/publications/security-advisories/2026-018
• 腾讯云安全通告：https://cloud.tencent.com/announce/detail/2525
• PHP 基金会公告：https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/
• 漏洞详情：https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w 、https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp