PHP 这次的漏洞，为什么值得你立刻查一遍服务器？

Jastar Wang原创2026/10/22大约 7 分钟

`PHP` 这次的漏洞，为什么值得你立刻查一遍服务器？

看到 PHP2Shell 的消息，不写 PHP 的开发者也值得查一遍自己的系统。主业务用 Java，但是公司官网、内容系统和某个老后台未必用的同一套技术。

1、先确认哪些服务用到了 `PHP`

ENISA 的通告提到了这件事：一些产品底层依赖 PHP，表面上不一定看得出来。排查时要把这些间接依赖算进去，优先处理公网服务；来不及修复的，可以考虑暂时隔离公网访问。〔1〕

这次公开的是两项 PHP 核心漏洞，CVE-2026-109618 和 CVE-2026-109619，合称 PHP2Shell。10 月 21 日，PHP 已经发布修复版本，官方建议尽快更新。〔2〕

`PHP` 分支	本次修复版本
8.2	8.2.35
8.3	8.3.36
8.4	8.4.27
8.5	8.5.12

图 1｜PHP 官方安全公告，2026 年 10 月 21 日。截图为公告标题，完整影响范围和更新说明见附录〔2〕。

2、两项漏洞，分别危险在哪里

CVE-2026-109618：内存不足时，清理流程误用了数据。

第一项漏洞出在内存不足时的处理流程里。PHP 的内部数据还没初始化完整，流程就被内存错误打断。随后清理请求时，又把这份不完整的数据当成正常数据使用，造成内存破坏。

在 Apache 的 mod_php 部署中，官方已验证攻击可以在业务代码执行之前触发。也就是说，后台即使有登录校验，也挡不住这条发生在更早阶段的攻击路径。〔3〕

CVE-2026-109619：上一个请求结束了，旧状态却还留着。

第二项是跨请求残留状态的问题。前一个请求使用的内存已经释放，工作进程里却还留着指向它的状态。同一个进程处理下一个请求时，可能再次访问这块失效的内存。能否利用，要看应用行为、配置和具体路径。官方没有给出能完整解决它的通用配置方案，仍然需要更新。〔4〕

PHP-FPM 也在这次的风险范围内。PHP 官方列出的部署方式包括 PHP-FPM、mod_php、php-cgi、FrankenPHP 和 LiteSpeed，其中 mod_php 风险最高。不能看到自己用的是 Nginx 加 PHP-FPM，就把这次通告划过去。〔2〕

还有，“远程代码执行”不等于直接拿到 root。已验证的攻击获得的是 Web 工作进程的账户权限，后续能读到什么、修改什么，要看权限配置和隔离情况。但业务进程本身就可能接触敏感数据，不必等到最高权限被拿走才着急。〔3〕

3、从排查到修复，按这几步处理

3.1、找到实际部署和负责人

把公司官网、内容管理系统、管理面板和第三方应用列出来，找到它们实际运行的机器、容器或托管服务。尤其是那些平时很少改动的系统，最好顺手确认一下还有谁在维护。漏洞通知转进群里以后，总得有人知道这件事归自己。

3.2、按更新渠道核对修复版本

确认用到了 PHP，再看软件是从哪里装的。自己安装官方版本，就按对应分支更新；使用发行版软件包或托管服务，就查提供方的安全公告。

这里容易误判的是版本号。发行版可能把安全补丁回退到已有版本，不一定跟着改成最新的上游版本号。比如 Ubuntu 24.04 的这次修复包是 8.3.6-0ubuntu0.24.04.13。如果只盯着开头的“8.3.6”，拿它与“8.3.36”比较，就可能误以为补丁没打上。要核对完整包版本。〔5〕

图 2｜Ubuntu 官方修复包版本表。重点看 Noble（24.04）这一行：安全补丁体现在完整包版本中。其他发行版应查各自公告，详见附录〔5〕。

旧版本也需要查清更新渠道。PHP 8.1 及更早版本已经没有常规上游更新，部分发行版和长期维护商仍提供回移补丁。本次 PHP 官方还提供了 7.4、8.0、8.1 的最小源码回移补丁，供特定场景使用，但这不代表这些分支恢复了常规支持。〔2〕

3.3、重启服务，再检查实际运行情况

更新软件包之后，Ubuntu 的说明明确提到，使用 PHP 的应用可能仍需重启；mod_php 部署要重启 Apache。即使启用了自动更新，也要处理服务重启的问题。〔5〕

需要核对这几项：

服务已按部署方式重启或替换。
实际接收请求的运行环境已更新，多节点逐个核对。
主要业务功能已通过回归。

容器部署要检查正在运行的实例。新镜像构建好了，还得确认旧实例已经替换。

如果暂时升不了级，就先降低公网暴露，再安排修复。官方给出的临时配置只能缓解部分攻击路径，不能改完一个参数就认为安全了。〔2〕

4、漏洞发现之后，后续谁来把它修复

这次消息里还有 AI 参与漏洞研究的部分。不过，PHP 基金会的复盘更让我关注。

OOM 问题的早期迹象，在 2024 年处理安全审计问题时就出现了。修复需要权衡兼容性、性能和扩展生态；当时缺少已确认的远程代码执行路径，加上团队资源和决策机制的问题，修复工作反复停滞。基金会承认，这里面有结构性的失败。〔6〕

AI 辅助研究参与了这次工作，而确认影响、修改代码、协调发布，仍然需要维护者投入时间。〔6〕一个问题已经被发现，和用户最终能装上修复版本，中间隔着的事情并不少。

我觉得团队排期时，也该给这些维护工作留点余地。升级运行时、检查旧系统、验证服务重启，做完以后可能没有多少新东西能演示，却不能一直靠紧急通告来催。

手上有网站或后台的，可以先把 PHP 的部署和更新情况查一遍。修复完以后，把包版本、重启时间和验证结果记在工单里，后面接手的人也能知道这次到底处理到了哪一步。

5、附录

〔1〕ENISA：PHP 严重漏洞联合通告：https://www.enisa.europa.eu/news/joint-statement-on-critical-php-vulnerabilities
〔2〕PHP 官方：严重远程代码执行漏洞安全公告：https://www.php.net/archive/2026.php#2026-10-21-5
〔3〕PHP 官方漏洞公告：CVE-2026-109618：https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
〔4〕PHP 官方漏洞公告：CVE-2026-109619：https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
〔5〕Ubuntu：PHP2Shell 修复说明：https://ubuntu.com/blog/php2shell-vulnerability-fixes-available
〔6〕PHP 基金会：本次安全更新与安全工作复盘：https://thephp.foundation/blog/2026/10/21/todays-php-security-release-and-how-were-strengthening-php-security/