紧急：PHP 两个致命 RCE 已修复（CVE-2026-109618 / CVE-2026-109619），PHP 站点立刻升级

PHP 官方已于 2026 年 10 月 21 日 14:00 UTC 发布紧急安全版本，修复两个可被未授权攻击者远程执行代码的漏洞：CVE-2026-109618 与 CVE-2026-109619，官方评级均为 CVSS v4.0 9.2。

这两个漏洞在 PHP 运行时层面，升级 WordPress 插件、执行 composer update 都解决不了，必须升级 PHP 本身。下面按区块拆开讲，每个区块都能单独照着做。

一、30 秒结论

所有对外提供 Web 请求的 PHP 服务器，今天必须升级。补丁打在 PHP 运行时上，应用层补丁无效。

按顺序做完这三件事：

查版本：确认每台服务器的 PHP 版本与运行形态。
升版本：升到对应分支的修复版本，重启全部 worker。
改配置：暂时升不了的先按「临时缓解」止血。

php.net 首页安全公告截图，标题为 Critical remote code execution vulnerabilities, update now，列出 PHP 8.5.12、8.4.27、8.3.36、8.2.35 为修复版本

图：php.net 首页 2026-10-21 的安全公告，明确给出四个修复版本并列出两类漏洞的原理。本文所有版本号以此为准。

二、两个漏洞，逐项对照

CVE-2026-109618：内存耗尽（OOM）破坏内部状态

内存耗尽可能让 PHP 中断在「内部请求数据只初始化了一半」的状态，随后的请求清理把这部分无效数据当有效数据使用，进而可被利用执行任意代码。

GitHub 通告编号：GHSA-w8hw-w9fx-j79w，标题为 RCE via OOM corruption。

利用条件：使用 PHP 默认的输入与内存限制即可，无需登录。

验证状态：mod_php 上已完成未授权 HTTP 利用验证；PHP-FPM 经源码分析认定受影响。

成功后果：代码以 Web worker 账号的权限运行。

GitHub 上 php-src 仓库 GHSA-w8hw-w9fx-j79w 安全通告页面，标题为 RCE via OOM corruption

图：官方 GHSA 通告页，CVE-2026-109618 的正式标题是「RCE via OOM corruption」。

图：Wiz 给出的攻击链示意，入口是一次可控的内存分配失败。

CVE-2026-109619：跨请求残留的全局状态

请求持有的内部状态在底层内存被释放后仍然存留。同一个 worker 处理下一个请求时，可能在正常初始化重置之前用到这份过期状态，构成 use-after-free 并导致代码执行。

GitHub 通告编号：GHSA-6wmf-4rv5-p3rp，标题为 RCE via stale global state。

已确认路径：fatal error backtrace、session upload progress 处理。

验证状态：PHP-FPM 路径已验证，但利用需要一个合适的应用层操作配合。

GitHub 上 php-src 仓库 GHSA-6wmf-4rv5-p3rp 安全通告页面，标题为 RCE via stale global state

图：官方 GHSA 通告页，CVE-2026-109619 的正式标题是「RCE via stale global state」。

图：Wiz 给出的攻击链示意，关键是跨请求复用的残留状态。

三、影响范围

部署形态

Apache mod_php：风险最高。
PHP-FPM、php-cgi、FrankenPHP、LiteSpeed：同样在范围内。

官方明确：mod_php 已验证存在一种利用方式，一个未授权请求即可在应用代码执行之前触发攻击。

依赖 PHP 的应用

WordPress、Drupal、Joomla、Magento。
ThinkPHP、Laravel、Discuz 等国产与开源系统。
各类自研后台与管理工具。

最容易被漏掉的

老旧站点与很少打开的内部工具。
控制面板、共享虚拟主机。
容器里的 PHP 基础镜像。
FrankenPHP 这类自带 PHP 运行时的静态二进制。

影响面：Wiz 估计该漏洞组合影响约七成互联网站点。

四、修复版本（按分支对号入座）

PHP 8.5 分支：升级到 8.5.12

PHP 8.4 分支：升级到 8.4.27

PHP 8.3 分支：升级到 8.3.36

PHP 8.2 分支：升级到 8.2.35

PHP 8.2 分支将于 2026 年 12 月 31 日 EOL，之后不再有安全修复，建议提前规划升级到受支持分支。

三条补充事实

发行版与 LTS 厂商已提前拿到补丁，可直接装安全包，版本号不一定与上游一致。
8.1 及更早版本官方不再支持，但已额外为 7.4、8.0、8.1 提供最小化源码 backport。
使用 rpms.remirepo.net 的用户，该志愿仓库当天不会提供更新，建议改用发行版包或自行编译。

五、升级命令

先确认现状

php -v
php -i | grep -i "Loaded Configuration"

php -v 看的是命令行 PHP，与 Web 服务器实际使用的 PHP 可能不是同一个二进制，两边都要查。

Debian / Ubuntu

apt update && apt install --only-upgrade php8.3-fpm
systemctl reload php8.3-fpm

RHEL / Rocky / Alma

dnf update php-fpm
systemctl reload php-fpm

Alpine

apk upgrade php83-fpm

容器

docker pull php:8.3-fpm-alpine

升级后必须重启或 reload 每一个 PHP worker 与常驻进程。容器化部署最容易漏：改了宿主机的 PHP 包，不等于换了容器里的 PHP。

六、临时缓解（升不了才做）

官方原话：以下措施只降低特定攻击路径的暴露面，不能让一个安装变安全。完整修复只有升级。

针对 CVE-2026-109618

memory_limit 设为 -1，用 php_admin_value 写死，避免被应用覆盖。
调低 post_max_size：无上传设为 8M，需上传设为 32M。
upload_max_filesize 保持小于 post_max_size。
在 Web 服务器或代理层限制请求大小、字段数、分段数与嵌套深度。
用容器或 cgroup 限制做兜底，策略最好是只杀受影响的 worker。
不要用 RLIMIT_AS 或 RLIMIT_DATA 替代，它们反而会制造漏洞所需的分配失败。

针对 CVE-2026-109619

设置 session.upload_progress.enabled=0，并重启每一个 worker。
必须写在 php.ini、FPM pool 或服务器配置里，确保在请求解析之前生效。
不要依赖 ini_set() 或 FPM 的 .user.ini，它们生效得太晚。
PHP 8.5 上额外设置 fatal_error_backtraces=0 并重启所有 worker。
移除会在初始化前产生诊断输出的无效或废弃配置。
用 error_reporting、display_errors 或 @ 把报错藏起来没有用。

可直接粘贴的 FPM 配置

; /etc/php/8.3/fpm/pool.d/www.conf
php_admin_flag[session.upload_progress.enabled] = off
php_admin_value[memory_limit] = -1
php_admin_value[post_max_size] = 8M

systemctl reload php8.3-fpm

改完要在「由 PHP-FPM 处理的请求」里确认配置真正生效，而不是在命令行里确认。用 mod_php 就写在 php.ini 里并重启 Apache。若站点把 session 存在 Redis 或数据库，该类 handler 不实现 strict mode 需要的 id 检查，相关设置不会生效。

七、攻击进展与排查

图：CyberInsider 的跟踪报道，记录了 Cloudflare 观察到的早期攻击尝试与 Wiz 的攻击链分析。

已观察到的情况

Cloudflare CTO Dane Knecht：已观察到早期攻击，并随新向量持续更新规则。
Cloudflare 已对 PHP 站点下发 WAF 规则，含免费客户，但这只是过渡手段。
英国 NCSC：立即修补，无法马上修复的系统考虑先下线。

排查清单

Web 目录下新增或改动时间异常的 PHP 文件。
PHP-FPM 或 Web 服务进程派生出的异常子进程。
可疑的 exec、system、passthru 调用。
异常出站连接。
模板与主题文件被篡改。

不要指望登录页或维护模式挡攻击：部分利用路径在任何应用代码执行之前就已触发。

八、四个常见误区

误区一：更新 CMS 就够了

漏洞在 PHP 运行时，更新 WordPress、升级插件、composer update 都碰不到它。

误区二：装了 WAF 就安全

WAF 只是虚拟补丁。官方与 Cloudflare 都强调仍需升级运行时。

误区三：PHP 8.2 能拖到年底

8.2 分支 2026 年 12 月 31 日 EOL，之后不再有安全修复。

误区四：PHP 7 等官方补丁就行

官方不为 8.1 及更早版本提供常规更新。只能靠发行版 backport、自行编译官方提供的最小补丁，或迁移到受支持版本。

九、VVCMS 用户须知

VVCMS 是 Go 语言单文件程序，不依赖 PHP 运行时，本身不受这两个漏洞影响。

但如果同一台服务器上还部署了 WordPress、ThinkPHP、Laravel 或其他 PHP 应用，请单独升级那套 PHP 运行时——漏洞打的是服务器上的 PHP，不是某个 CMS。

十、参考来源

以下均为一手来源，按可信度排序。

PHP 官方安全公告与版本发布说明（含修复版本与缓解建议）：https://www.php.net/
GitHub php-src 通告 CVE-2026-109618 / GHSA-w8hw-w9fx-j79w：https://github.com/php/php-src/security/advisories/GHSA-w8hw-w9fx-j79w
GitHub php-src 通告 CVE-2026-109619 / GHSA-6wmf-4rv5-p3rp：https://github.com/php/php-src/security/advisories/GHSA-6wmf-4rv5-p3rp
官方为 PHP 7.4 / 8.0 / 8.1 提供的源码 backport 分支：https://github.com/php/php-src/tree/PHP-8.1-CVE-2026-109618-109619
BleepingComputer：PHP warns admins of two critical flaws：https://www.bleepingcomputer.com/news/security/php-warns-admins-of-two-critical-flaws-emergency-patches-coming-tomorrow/
Help Net Security：PHP2Shell: Critical PHP vulnerabilities patched：https://www.helpnetsecurity.com/2026/10/21/php2shell-php-vulnerabilities-patched-cve-2026-109618-cve-2026-109619/
CyberInsider：PHP releases emergency fixes for critical PHP2Shell vulnerabilities：https://cyberinsider.com/php-releases-emergency-fixes-for-critical-php2shell-vulnerabilities/
Cyber Kendra：泄露与 embargo 时间线：https://www.cyberkendra.com/2026/10/php-cve-2026-109618-cve-2026-109619-rce.html
Flavio Copes：修复版本对照与 Laravel 平台动作：https://flaviocopes.com/php-security-update

本文信息截至 2026 年 10 月 21 日。安全事件进展很快，执行前请以 PHP 官方公告与你的发行版安全通告为准。