php2shell漏洞需升级至官方修复版并重启服务才能消除，CentOS/Rocky用户因仓库滞后须手动验证版本、构建日期及Server API，并启用extras仓库或下载签名RPM，安装后必须restart而非reload。
php2shell 漏洞不是配置问题，也不是应用层补丁能绕过的——只要 PHP 运行时版本没升到官方修复版，就还在射程内。CentOS 和 Rocky Linux 用户尤其要注意：它们默认的 php 包长期滞后，系统级 yum update 很可能根本不会拉到 8.5.12/8.4.27 这类安全更新。
怎么确认你当前 PHP 版本是否已修复
别信包管理器说的“已是最新”，要直接看 PHP 自己报的版本和构建时间：
- 执行
php -v，输出必须包含8.5.12、8.4.27、8.3.36或8.2.35中的任意一个；低于这些版本号的，哪怕只差一个小数点（比如8.4.26），都未修复 - 执行
php -i | grep "Build Date"，确认构建日期是 2026-10-21 或之后；早期编译的 8.4.27 镜像（比如 Chainguard 在 10 月 21 日凌晨发布的）可能不含完整补丁，仅靠版本号不够可靠 - 检查
Server API：运行php -i | grep "Server API"，若显示Apache 2.0 Handler（即 mod_php），风险最高，必须升级+重启 httpd；若为FPM/FastCGI，则需重启php-fpm进程，不能只 reload
为什么直接 yum update php 在 CentOS/Rocky 上大概率失败
因为主流发行版仓库尚未同步 PHP 官方补丁。CentOS Stream 9、Rocky Linux 9 的默认 appstream 仓库仍停留在 PHP 8.1 或 8.2 的 EOL 分支；CentOS 7 的 epel 甚至还在推 PHP 5.4 兼容包。
- Rocky Linux 用户应优先启用
rocky-extras仓库，并确认其中已上架php-8.4.27-1.el9或更高版本（截至 2026-10-22 中午，部分镜像源尚未同步） - CentOS 7 用户没有官方支持路径，必须手动下载 RPM：从 vault.centos.org 找第三方维护者打包的
php82-php-8.2.35-1.el7.x86_64.rpm，注意核对 GPG 签名 - 所有用户在安装 RPM 后，必须运行
rpm -V php82-php验证文件完整性，防止中间人篡改
升级后不重启服务 = 白升
这两个漏洞的机制决定了：旧 worker 进程里残留的内存状态，会污染后续请求。哪怕你已经装了新包，只要老进程还在跑，风险就持续存在。
立即学习“PHP免费学习笔记（深入）”；
- mod_php：必须执行
systemctl restart httpd，reload不生效 —— Apache 不会重新加载 PHP 模块 - PHP-FPM：执行
systemctl restart php-fpm，不要用reload；若使用 socket 模式，确认/var/opt/remi/php84/run/php-fpm/www.sock（路径依版本而异）权限未被继承旧进程的 uid/gid - LiteSpeed 或 FrankenPHP：查进程树，用
kill -USR2强制滚动 worker，不能依赖控制台“软重启”
验证是否真修复，别只看 phpinfo()
最简验证方式是构造一个内存压力请求，观察是否还能触发 OOM 后的状态复用。生产环境慎用，但可快速定位风险：
- 临时加一段脚本：
<?php a="str_repeat('x',"><!--?php--><!--?php--><!--?php--><!--?php--><!--?php-->?php>，访问它并观察错误页是否返回Fatal error: Allowed memory size exhausted而非 segfault 或静默崩溃 - 更稳妥的方式是抓包看响应头：修复后的 PHP 在 OOM 场景下会强制发送
X-PHP-Response-Code: 500，未修复版本可能无此 header 或返回 200 - 若用 WAF 或 RASP 工具，检查其日志里是否还有
CVE-2026-109618相关告警；有则说明流量仍经过未修复的实例
补丁本身只是起点。真正容易被忽略的是：同一台机器上可能混用多个 PHP 版本（比如 cPanel 用 EA4 装了一套，网站又自己编译了一套），或者容器里跑着旧镜像但宿主机已升级——这种“局部修复”反而会制造盲区。
