Ant Ping

PHP 爆出两个严重 RCE 漏洞 - CVE-2026-109618 和 CVE-2026-109619 修复指南

发表于 2026年10月22日 11:58 预计阅读 30 分钟
目录

2026 年 10 月 21 日，PHP 官方发布紧急安全公告，披露并修复了两个影响 PHP 核心运行时的严重安全漏洞：

  • CVE-2026-109618：内存耗尽处理异常导致的远程代码执行漏洞。

  • CVE-2026-109619：全局状态残留导致的释放后使用（Use-After-Free）漏洞。

两个漏洞的 CVSS v4 评分均为 9.2 分（Critical），在满足特定利用条件时，攻击者无需身份认证即可执行远程代码。

此次漏洞影响范围广泛，涉及 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed 等 PHP Web 运行环境。

对于使用 PHP 部署网站、API 服务以及各类 Web 应用的管理员，建议立即检查服务器版本并安装安全补丁。

一、漏洞基本信息

项目 详细信息
漏洞编号 CVE-2026-109618、CVE-2026-109619
漏洞类型 远程代码执行（RCE）、Use-After-Free
严重程度 Critical（严重）
CVSS v4 评分 9.2
公布日期 2026 年 10 月 21 日
是否需要登录 特定利用路径无需认证
影响组件 PHP 核心运行时
修复状态 官方已发布补丁

这两个漏洞也被部分安全机构统称为 PHP2Shell。

与常见的 SQL 注入、文件上传或应用层代码执行漏洞不同，此次问题存在于 PHP 自身的内存管理和请求生命周期处理机制中。

这意味着即使业务代码没有明显的安全缺陷，运行在受影响 PHP 环境上的网站仍然可能面临风险。

二、哪些 PHP 版本受到影响？

根据 PHP 官方安全公告，受影响的主要版本及对应修复版本如下：

PHP 分支 受影响版本 安全修复版本
PHP 8.5 8.5.11 及更早 8.5.12
PHP 8.4 8.4.26 及更早 8.4.27
PHP 8.3 8.3.35 及更早 8.3.36
PHP 8.2 8.2.34 及更早 8.2.35
PHP 8.1 及更早 已停止官方常规维护 建议迁移至受支持版本

值得注意的是，此次漏洞并不是只影响 PHP 7.x 等老版本。

即使使用 PHP 8.4 或 PHP 8.5，只要没有更新到对应的安全修复版本，同样可能受到影响。

部分 Linux 发行版和商业长期支持服务可能会将补丁回移植到旧版本，因此不能仅凭版本号判断所有发行版软件包是否安全，还需要检查软件包维护方的安全公告。

三、漏洞一：CVE-2026-109618 内存耗尽导致 RCE

1. 漏洞原理

PHP 在处理请求时，需要不断分配和释放内存。

当 PHP 达到内存限制，或者内存分配失败时，会触发内存耗尽（Out of Memory，OOM）处理机制。

正常情况下，PHP 应当终止当前操作，并安全释放相关资源。

但是在受影响的版本中，如果内存分配失败发生在某些内部数据尚未完成初始化的阶段，PHP 可能提前退出当前处理流程，导致部分内部数据处于不一致状态。

随后，PHP 在请求清理阶段可能错误地读取或使用这些数据，造成内存损坏。

在特定环境下，这类内存损坏可能进一步发展为远程代码执行。

2. 为什么危险？

该漏洞的危险性在于它涉及 PHP 底层的内存处理，而不是单一业务功能。

研究人员已经在使用 Apache mod_php 的环境中验证了无需身份认证的远程代码执行，并在 PHP-FPM 的部分应用代码路径中确认了 RCE 风险。

成功利用后，攻击者可能获得 PHP Web 工作进程对应的系统权限。

这不等于自动获得 root 权限，但仍可能威胁网站文件、数据库凭据以及其他可由 Web 进程访问的资源。

四、漏洞二：CVE-2026-109619 全局状态残留漏洞

1. 漏洞原理

PHP 工作进程可以连续处理多个 HTTP 请求。

为了提高执行效率，PHP 会在进程内部维护错误处理、会话管理及其他运行状态。

正常情况下，一个请求结束后，指向该请求内存的内部状态应当被清理或重置。

但在某些异常处理路径中，例如发生致命错误时，部分状态可能没有被正确清理。

这样一来，后续请求可能访问已经释放的内存，产生 Use-After-Free（释放后使用）问题。

2. 可能造成什么影响？

Use-After-Free 是一类危险的内存安全问题，可能导致：

  • PHP 工作进程异常退出。

  • 敏感内存信息泄露。

  • 服务稳定性下降。

  • 在特定条件下执行攻击者控制的代码。

安全研究已经验证了该漏洞在 Apache mod_php 环境中的远程代码执行路径，也确认了涉及 PHP-FPM 的部分会话生命周期利用路径。

因此，不能简单认为使用 Nginx + PHP-FPM 就能够完全避免此次漏洞。

五、如何检查服务器是否存在风险？

1. 查看 PHP 版本

登录服务器执行：

php -v

例如输出：

PHP 8.4.26 (cli)

如果服务器使用的是官方未修复构建，那么 PHP 8.4.26 属于受影响版本，应当升级到 PHP 8.4.27 或更新的安全版本。

注意，php -v 检查的是命令行 PHP 版本，不一定代表网站实际使用的 PHP 版本。

2. 检查 PHP-FPM

可以执行：

php-fpm -v

对于安装了多个 PHP 版本的服务器，也可以查看运行中的进程：

ps aux | grep '[p]hp-fpm'

然后结合 PHP-FPM 服务配置，确认网站实际使用的 PHP 版本。

3. 检查 Docker 环境

如果网站使用 Docker 部署，可以执行：

docker ps

查看 PHP 容器使用的镜像，再进入对应容器检查：

docker exec <container_name> php -v

其中 <container_name> 需要替换为实际容器名称。

需要注意，Docker 镜像标签和 PHP 版本号并不总能完整反映补丁状态，尤其是使用自定义镜像时。

4. 检查服务器面板

如果使用宝塔面板等管理工具，可以进入 PHP 管理页面查看当前安装版本。

确认面板是否提供安全更新。如果面板的软件包更新存在延迟，应当关注其官方安全公告，避免盲目使用来源不明的第三方补丁。

六、如何修复这两个 PHP 漏洞？

最有效的修复方式是安装官方或发行版维护方提供的安全更新。

建议至少升级至以下版本：

当前 PHP 分支 最低修复版本
PHP 8.2 8.2.35
PHP 8.3 8.3.36
PHP 8.4 8.4.27
PHP 8.5 8.5.12

对于 PHP 8.1 及更早版本，建议尽快规划迁移。

1. Linux 服务器升级

如果 PHP 由操作系统的软件包管理器维护，应优先通过对应软件源安装安全更新。

Debian、Ubuntu 系统可以先执行：

sudo apt updateapt list --upgradable

确认 PHP 相关更新后，再根据实际安装的软件包进行升级。

使用发行版软件包时，应结合对应发行版的安全公告确认修复状态，而不是仅依赖上游 PHP 版本号。

2. Docker 环境升级

如果使用官方 PHP Docker 镜像，可以选择已修复的版本，例如：

docker pull php:8.4.27-fpm

然后重新构建业务镜像并部署。

如果使用 Docker Compose，可以根据实际项目配置执行：

docker compose build --pulldocker compose up -d

注意，只有项目镜像确实基于已修复的 PHP 版本重新构建时，才能完成漏洞修复。

3. 重启 PHP 工作进程

安装补丁后，应按照服务器的部署方式重启或滚动替换 PHP 工作进程，确保旧进程不再运行。

例如，使用 systemd 管理 PHP-FPM 的服务器可以执行：

sudo systemctl restart php8.4-fpm

实际服务名称需要根据系统配置调整。

对于容器环境，应确保所有 PHP 容器都已经替换为修复后的镜像。

七、无法立即升级怎么办？

如果生产环境暂时无法完成升级，可以参考 PHP 官方建议采取临时风险缓解措施。

但必须强调：临时缓解措施不能代替安全补丁。

1. 限制不必要的公网访问

对于管理后台、测试环境和内部接口，应尽量限制访问来源。

可以通过 VPN、反向代理访问控制等方式减少暴露面。

2. 限制 HTTP 请求体大小

根据业务需求，在 Web 服务器和 PHP 层设置合理的请求体大小限制。

例如：

post_max_size = 8Mupload_max_filesize = 2M

如果业务需要上传大文件，应根据实际需求调整，不能直接套用示例值。

这些限制有助于减少部分恶意请求带来的风险，但无法完整阻止漏洞利用。

3. 临时关闭上传进度会话功能

针对 CVE-2026-109619 的部分已确认利用路径，PHP 官方建议在不依赖该功能的情况下设置：

session.upload_progress.enabled = 0

配置应在请求处理前生效，并在修改后重启全部相关 PHP 工作进程。

此措施只能阻断部分已确认路径，不能完全修复漏洞。

4. 加强运行环境隔离

建议让 PHP 工作进程使用独立的低权限系统用户运行。

同时限制不必要的文件写入权限，并隔离敏感配置、数据库账号和其他服务。

对于容器环境，也应配置合理的资源限制和安全策略。

5. 检查异常日志

重点关注 PHP 工作进程异常退出、内存耗尽、异常请求量以及可疑文件变更等情况。

这些现象不能单独证明服务器遭到漏洞攻击，但可以作为安全排查的线索。

八、PHP 网站管理员应该注意什么？

此次漏洞提醒我们，网站安全不仅仅是防止 SQL 注入、XSS 或弱密码。

PHP、Java、Node.js 等运行环境本身，也可能出现严重的底层安全漏洞。

对于长期运行的生产网站，建议建立定期更新机制：

  1. 定期关注 PHP 官方安全公告。

  2. 及时更新 PHP 运行环境及扩展。

  3. 保持网站程序、框架和依赖处于受维护状态。

  4. 建立测试环境，提前验证升级兼容性。

  5. 对重要业务保留可验证的备份和回滚方案。

  6. 监控服务器日志及异常进程行为。

尤其是长期没有升级过的 PHP 网站，更应该尽快进行一次完整的运行环境安全检查。

九、总结

2026 年 10 月 21 日披露的 CVE-2026-109618 和 CVE-2026-109619，是两项影响 PHP 核心运行时的严重安全漏洞。

它们分别涉及内存耗尽处理和全局状态生命周期管理，特定条件下可以导致未经身份认证的远程代码执行。

由于影响范围覆盖多个 PHP 8.x 版本，以及已经停止官方维护的旧版本，建议所有 PHP 网站管理员尽快确认自身环境的补丁状态。

对于存在风险的服务器，应优先安装官方安全更新，而不是长期依赖 WAF 或临时配置进行防护。

参考资料

广告广告