PHP 两个 9.2 分远程代码执行漏洞遭在野利用：无需认证即可执行代码，网站该如何排查与修复-速维云

事件概述：PHP 一天之内连发两个严重 RCE 漏洞

2026 年 10 月 20 日，PHP 官方安全团队预告了一次紧急安全发布；10 月 21 日 13:30（UTC），修复版本正式上线，覆盖 8.5、8.4、8.3、8.2 四个维护分支。两个漏洞分别是 CVE-2026-109618（GHSA-w8hw-w9fx-j79w）和 CVE-2026-109619（GHSA-6wmf-4rv5-p3rp），CVSS 评分均为 9.2，都允许未经认证的攻击者在受影响服务器上执行任意代码。研究人员将这套利用方式称为 "php2shell"——攻击者发送一条特制的 multipart POST 上传请求，不需要任何账号，也不需要诱导用户点击，就能在 PHP 工作进程权限下执行代码，进而在服务器上植入 WebShell。

漏洞披露后，CERT-EU、加拿大网络安全中心、瑞士国家网络安全中心、香港 HKCERT 等机构在 24 小时内相继发布警报；HKCERT 与国内安全厂商监测显示漏洞已发现在野利用。PoC 与技术细节已经公开，这意味着自动化扫描和攻击随时可能出现。

漏洞原理：一个和"内存耗尽"有关，一个和"陈旧状态"有关

两个漏洞的共同点，是 PHP 在请求生命周期的边界上"把不可信的状态当成了可信状态"。

CVE-2026-109618 与内存耗尽（OOM）处理有关：PHP 通过 longjmp() 中断超出 memory_limit 的请求。如果中断发生在内部请求数据只完成部分初始化的时刻（例如正在解析 multipart 文件上传），后续的请求清理就可能把未初始化的内存当作有效数据释放或使用，而这块内存里可能还留着攻击者可控的早期分配内容，最终造成内存破坏并走向代码执行。

CVE-2026-109619 与跨请求的全局状态有关：PHP 的某些全局状态会临时指向请求内存，请求结束、内存释放后，这些状态没有被正确重置或被重新填充，同一个 worker 处理后续请求时就会在初始化之前访问已释放的内存，形成释放后使用（UAF）。

所有处理 Web 请求的 PHP 形态都受影响：PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed。PHP 官方认为 mod_php 风险最高，因为已有演示表明一条未认证请求就能在应用代码执行前触发漏洞。

影响范围：不只是"某个框架"，而是整个 Web 底层

按 W3Techs 统计，全球约四分之三的网站服务器端使用 PHP，WordPress、Drupal、Joomla、MediaWiki、Magento、phpMyAdmin、Nextcloud、Laravel、Symfony 等主流应用都构建在 PHP 之上。受影响版本为 PHP 8.5.x（低于 8.5.12）、8.4.x（低于 8.4.27）、8.3.x（低于 8.3.36）、8.2.x（低于 8.2.35）。已停止维护的 8.1 及更早版本官方不再发布常规补丁，但 PHP 团队为 7.4/8.0/8.1 提供了最小化源码 backport，供自行编译或有 LTS 厂商支持的场景使用。

需要特别提醒的是：很多站长以为自己"没有直接跑 PHP"，但实际上大量虚拟主机、面板、容器镜像、网络 appliances 内部都内置了 PHP。共享主机、VPS 面板、宝塔/XAMPP 类集成环境、Docker 官方 PHP 镜像，只要版本低于上述修复版，都在影响范围内。

PHP 漏洞排查可结合 Web 服务器访问日志与错误日志进行（示意图）

为什么普通站长和中小企业运维也要重视

第一，利用门槛极低：无需认证、无需用户交互，一条 HTTP 请求即可触发，且 PoC 已公开，脚本化攻击和小型勒索团伙都能直接使用。第二，影响的是进程权限：漏洞执行发生在 PHP 工作进程账户下，攻击者拿到的是 Web 目录写权限和命令执行能力，挂马、挂 WebShell、挖矿、勒索的完整链路都已经成熟。第三，多租户环境会放大风险：共享主机上一台站点失陷，同服务器其他站点都可能被横向波及。

排查思路：先确认版本，再看日志

1. 确认版本：有服务器权限的可执行 php -v 或 php-fpm -v 查看实际运行版本；虚拟主机用户可通过后台或工单向服务商确认。注意以实际输出为准，不要只看包管理器版本号，发行版仓库可能存在同步延迟。

2. 梳理资产：列出所有使用 PHP 的服务——不止公网网站，还包括内部系统、API 服务、计划任务、容器内的 PHP 镜像。

3. 检查日志：重点看漏洞披露时间点之后，Web 访问日志中是否出现大量异常 multipart POST 请求、指向不存在脚本的请求，以及错误日志中的 OOM 与致命错误记录。

4. 检查失陷迹象：网站目录（尤其是上传目录、临时目录、主题插件目录）是否出现来源不明的新文件、可疑 webshell、异常计划任务或异常外连。

修复与缓解建议

根本修复是升级：PHP 8.2 升级到 8.2.35，8.3 升级到 8.3.36，8.4 升级到 8.4.27，8.5 升级到 8.5.12，或使用发行版/LTS 厂商已 backport 补丁的对应包（包版本号不变不等于没有补丁，以厂商安全公告为准）。升级后必须重启 Apache、PHP-FPM 及所有常驻 worker，只替换二进制不重启不能消除风险；容器环境应重新构建镜像，Kubernetes 环境滚动重启 Pod，并确认没有旧 ReplicaSet 继续服务。生产环境重启建议先在测试环境验证，并选择业务低峰期执行。

官方临时缓解（仅降低特定攻击路径，不等于修复）：通过 FPM pool 的 php_admin_value 或 Apache 配置将 memory_limit 设为 -1（必须写在服务端配置里，不能依赖业务代码 ini_set，并确认没有 pool/目录/应用再把有限值加回来）；关闭 session.upload_progress.enabled；PHP 8.5 额外设置 fatal_error_backtraces=0。WAF 规则可作为临时缓冲，但无法拦截所有攻击变种，也防不住绕过 CDN 直连源站的攻击。官方特别提醒：不要使用 RLIMIT_AS/RLIMIT_DATA 作为缓解手段，这类限制会导致 mmap 失败，反而会触发 CVE-2026-109618 依赖的 longjmp 路径。

对于暂时无法升级的系统，可考虑将互联网暴露面收缩到必要范围，加强访问控制与日志监控。所有操作请以 php.net 官方公告和所用发行版/厂商的安全通告为准。