PHP2Shell 漏洞（CVE-2026-109618 / 109619）：检查并修补你的 PHP 服务器

2026 年 10 月 21 日，PHP 官方为 PHP 核心中的两个严重漏洞发布了紧急版本，编号 CVE-2026-109618 和 CVE-2026-109619，被称为「PHP2Shell」。两个漏洞的 CVSS v4.0 评分都是 9.2，都可能导致未认证的远程代码执行。发布前流出的报告写的是 10.0 分，PHP 团队说这个分数有误，但实际风险没有区别：任何能向你的 PHP 应用发送 HTTP 请求的人，都可能在服务器上执行代码。

Cloudflare 已经观测到针对这两个漏洞的攻击流量，这不是可以「下个迭代再修」的问题。

到底哪里出了问题

两个漏洞都在请求处理流程里，而不在某个框架或插件中，所以所有 PHP 应用都在影响范围内：

• CVE-2026-109618：内存不足（OOM）处理中的内存破坏。请求数据可能只初始化了一部分，却在清理阶段被当成有效数据使用。
• CVE-2026-109619：释放后重用（use-after-free）。上一个请求的状态没有被清掉，同一个 worker 处理的下一个请求可以读到它。

WordPress、Laravel、Drupal、Magento 还是手写的 PHP，只要运行在未修补的 PHP 上，都受影响。

受影响版本与修复版本

PHP 8.1、8.0 和 7.4 已经停止维护，官方不会发布补丁。社区有面向 7.4 到 8.1 的源码回移补丁，部分 Linux 发行版和主机面板（包括 Plesk）也提供自己的修补版本，但必须向供应商确认，不能想当然。

怎么检查你的服务器

在服务器上，这是最准确的方法：

php -v
# PHP 8.3.36 (cli) ...  → 已修复

注意，命令行和 Web 服务器可能用的不是同一个 PHP。要确认 Web 服务器实际运行的版本：临时放一个 phpinfo() 页面（看完立刻删除）、查看主机面板里的 PHP 版本选择，或者对 FPM 运行 php-fpm8.3 -v。

从外部看，很多服务器仍会在 X-Powered-By 响应头里暴露版本号：

curl -sI https://example.com | grep -i x-powered-by
# X-Powered-By: PHP/8.1.29   → 已停止维护，存在漏洞

免费网站漏洞扫描器会读取这个响应头，直接告诉你该版本是否已停止维护、是否受 PHP2Shell 影响。如果没有这个响应头，说明配置得不错，但也意味着你需要到服务器上自己确认。

怎么修补

1. 升级 PHP 软件包到对应分支的修复版本（Debian/Ubuntu 通过你使用的 PHP 软件源，RHEL 通过 Remi 或 AppStream，Docker 则修改 php: 镜像标签并重新构建）。
2. 重启所有 PHP worker。 只装新包是不够的，旧的 PHP-FPM、Apache mod_php 或 RoadRunner 进程仍把有漏洞的代码留在内存里。执行 systemctl restart php8.3-fpm（或对应命令），然后从 Web 端确认新版本。
3. 托管主机： 查看主机商的状态页或更新日志里有没有 PHP2Shell 相关更新。如果没提到，提交工单问清楚你用的是哪个版本。
4. PHP 8.1 或更早版本： 现在就规划升级到 8.4 或 8.5。回移补丁只能争取时间，不能带来安全；下一个 PHP 安全漏洞不会再有人帮你回移。

如果今天没法升级

PHP 团队发布了临时缓解措施：

• 关闭会话上传进度：session.upload_progress.enabled = Off。
• PHP 8.5 上关闭致命错误回溯（fatal error backtraces）。
• 修改配置后重启所有 PHP worker。

容器或 cgroup 内存限制能增加利用难度，但不是完整的缓解措施。在安排升级期间，可以用 CDN 的 WAF 规则拦截已知的攻击特征。

修补之后

• 再次确认 Web 服务器报告的版本，而不只是命令行版本。
• 设置 expose_php = Off 关闭版本暴露，让下一个扫描器（不管善意与否）没那么容易识别你。
• 如果服务器已经暴露了好几天，检查有没有被入侵的迹象：上传目录里多出来的 PHP 文件、新增的管理员账号、陌生的定时任务。

然后再扫描一次，确认版本标识已经消失，也没有其他暴露。如果你更希望有人帮你处理升级，集中修复服务包含在你的服务器上修补 PHP2Shell 并重启 worker。