1 找出服务器上的每一个 PHP

许多服务器运行不止一个 PHP：系统软件包、控制面板安装的版本（cPanel EA-PHP、Plesk、CWP/CloudLinux alt-php、DirectAdmin）、容器以及 cron 使用的命令行构建。凡是处理 Web 请求的，都必须更新。

运行 php -v，用 ps aux | grep php-fpm 列出 php-fpm 进程，并查看面板中的 PHP 版本选择器。

2 更新到已修复版本

上游的已修复版本为 8.5.12、8.4.27、8.3.36 和 8.2.35。发行版软件包可能以较旧的版本号包含修复 — 请在更新日志中查找 CVE-2026-109618 和 CVE-2026-109619。

PHP 8.1 及更早版本不会获得 PHP 项目的新版本。已为从源码构建的用户发布了针对 7.4、8.0 和 8.1 的最小源码补丁，但长久之计是迁移到受支持的分支。

Debian / Ubuntu（发行版软件包）

安装发行版的安全更新并重启 PHP。版本号可能保持不变；软件包更新日志中会列出该 CVE。

sudo apt update && sudo apt install --only-upgrade 'php*'
sudo systemctl restart 'php*-fpm' apache2 2>/dev/null
apt changelog php8.3-fpm | grep -i -m3 CVE-2026-1096

RHEL / AlmaLinux / Rocky (dnf)

为您的 PHP 模块流应用供应商勘误更新，然后重启。

sudo dnf upgrade --refresh 'php*'
sudo systemctl restart php-fpm httpd
rpm -q --changelog php-common | grep -i -m3 CVE-2026-1096

Docker / 官方 php 镜像

使用已修复的标签拉取或重新构建，并重新创建容器。

docker pull php:8.3-fpm   # must report 8.3.36 or later
docker compose up -d --build --force-recreate
docker compose exec app php -v

cPanel、Plesk、CWP、DirectAdmin

使用面板的更新工具更新每一个已安装的 PHP 版本（EA-PHP、Plesk PHP 处理程序、alt-php、CustomBuild），然后重启 PHP-FPM。面板经常为个别网站保留旧版本 — 也要更新或删除它们。

共享主机或托管主机

您通常无法自行更新 PHP。请使用结果卡片中的消息，向服务商询问确切版本、修补日期，并确认工作进程已重启。

Windows / IIS

从 windows.php.net 下载已修复的构建，替换 PHP 目录，并回收 IIS 应用程序池。

3 重启所有 PHP 进程

安装软件包不会改变已在运行的代码。请重启 PHP-FPM、Apache（使用 mod_php 时）、LiteSpeed、FrankenPHP、队列工作进程和进程管理器。对于容器，请重新构建或拉取新镜像 — 重启同一镜像并不会安装补丁。

4 验证

对每个可执行文件运行 php -v，并确认正在运行的进程使用的是新构建（例如 ls -l /proc/$(pgrep -o php-fpm)/exe 的输出中不应出现“deleted”）。然后再次运行本检测工具。

5 如果今天无法更新

在能够更新之前，请应用下面的部分缓解措施，并限制可访问该网站的范围。这些措施能降低风险，但不能消除风险。

6 检查入侵迹象 — 并更换机密信息

如果存在漏洞的网站曾可从互联网访问，请检查 2026 年 10 月 20 日以来的活动：PHP-FPM 或 Apache 错误日志中的 PHP 工作进程崩溃（SIGSEGV）、Web 根目录中新增或被修改的 PHP 文件、新的 cron 任务、新的管理员账户，以及异常的出站连接。

由于 CVE-2026-109619 可以在不运行任何代码的情况下暴露 PHP 进程内存，文件系统干净并不能证明没有发生泄露。对于曾暴露的网站，请更换数据库密码、API 密钥、支付和邮件凭据，并使用户会话失效。

7 更新之后

此修复引入了新的硬性内存限制：达到该限制的进程会被立即终止，关闭处理函数不会运行。请检查应用程序在内存紧张时的表现，将 memory_limit 与 post_max_size 和 max_input_nesting_level 一并检查，并撤销在打补丁前临时设置的 memory_limit = -1。用 expose_php = Off 隐藏版本只是可选的加固措施，并非修复。

部分缓解措施（来自 php.net 和安全公告）

这些措施只能收窄已知的攻击途径。php.net 指出，更新是唯一安全的选择。

; php.ini / FPM pool (php_admin_value) — 设置后重启所有工作进程
session.upload_progress.enabled = 0
fatal_error_backtraces = 0        ; PHP 8.5
post_max_size = 8M                ; 32M 如需上传功能
max_input_nesting_level = 16      ; default 64
display_errors = 0

; FPM pool
pm.max_requests = 200

请在 php.ini、PHP-FPM 池（php_admin_value）或服务器配置中设置这些选项，而不要使用 ini_set() 或 .user.ini，然后重启工作进程。安全公告和研究团队提出的其他措施：

memory_limit = -1 可以阻断部分依赖 PHP 自身内存限制的途径，但会把内存耗尽交给操作系统处理 — 只能与 cgroup v2 的 memory.max 限制一起使用。不要使用 RLIMIT_AS 或 RLIMIT_DATA；它们可能触发相同的漏洞途径。
在表单允许的范围内尽量降低 max_input_nesting_level。
降低 PHP-FPM 的 pm.max_requests，使工作进程更频繁地回收（有性能代价）。
在 Web 服务器或代理上限制请求大小、字段数量和嵌套深度；删除无效或已弃用的按请求 INI 设置。
SELinux 或 AppArmor 策略可以限制被入侵的工作进程能运行的内容 — 它们能减轻影响，但不能防止内存泄露。

参考资料

来源：php.net 安全公告，2026 年 10 月 21 日。最后核实于 2026-10-23。