1. 找到实际 Web 运行时
记录 PHP 分支、完整包修订号、安装来源、扩展、服务名和站点处理器。CLI 和 Web 可能使用不同二进制。多版本面板需逐站映射，盘点所有 FPM 池、Apache、容器镜像、队列进程和部署副本。生产变更前准备备份，并验证回滚方案。
2. 安装含补丁的构建
首个修复版本为 PHP 8.2.35、8.3.36、8.4.27 和 8.5.12。选择当前受支持分支或兼容的新分支，同步升级扩展，并测试应用兼容性与健康检查。从 PHP 或对应厂商渠道获取构建；CMS 更新和 WAF 规则均不能代替解释器补丁。
| PHP 分支 | 低于此版本的上游发行版 | 首个修复版本 | 安全支持结束 |
|---|---|---|---|
| PHP 8.5 | < 8.5.12 | ✓ 8.5.12 | 2029年12月31日 |
| PHP 8.4 | < 8.4.27 | ✓ 8.4.27 | 2028年12月31日 |
| PHP 8.3 | < 8.3.36 | ✓ 8.3.36 | 2027年12月31日 |
| PHP 8.2 | < 8.2.35 | ✓ 8.2.35 | 2026年12月31日 |
这些分支不会获得 PHP 项目常规版本更新。7.4、8.0、8.1 有最小源码回移植；厂商补丁状态需单独核实。 阅读指南 ↗
发行版版本号与补丁回移植
Ubuntu、Debian 和企业 Linux 常保留旧的上游版本号，通过软件包修订加入安全补丁。仅看到 8.3.6，既不能证明受影响，也不能证明已修复。须同时匹配系统版本、软件源、架构、已安装修订和两个 CVE 的厂商状态。本工具不编造包修复门槛。
3. 重启并验证所有实例
新文件不会自动替换内存中的旧工作进程。mod_php 需要重启 Apache，FPM 需重启对应服务及进程池，也要重启常驻队列和计划任务。检查服务启动时间、Web 实际版本、包修订、健康状态和每个负载均衡副本。临时诊断页用完立即删除，切勿公开保留 phpinfo()。
命令示例 / INVENTORY
php -v
php --ini
# Check the executable used by the Web service separately.
php-fpm -v
# On versioned installations, for example:
php-fpm8.3 -v修复指南
Ubuntu 与 Debian
确认 php*-common 和实际 Web 处理器的软件包，分别查看 Ubuntu 或 Debian 对两个 CVE 的记录。下方命令以 PHP 8.3 举例，应替换成实际分支。确认已启用仓库提供修复包后再升级。changelog 缺失或未提及 CVE 时，应查厂商公告，不能把没有记录当作安全。
阅读指南RHEL、Rocky、AlmaLinux 等系统
确认 PHP 来自系统仓库、应用流还是第三方源，查询 RPM 完整修订和厂商安全勘误。保持软件包在同一兼容流。示例针对未加版本前缀的 php-* 包；并行安装及面板管理的包名不同。第三方源须提供同时包含两个修复的依据。
阅读指南Docker 与容器镜像
重启原有容器不会安装 PHP 补丁。需拉取已修复基础镜像、重建应用镜像，并替换所有运行容器。生产环境固定经验证的镜像摘要，滚动更新后逐副本检查。自建及厂商镜像需单独提供补丁依据。示例使用 PHP 8.4.27 FPM，Compose 服务占位符须换成真实名称。
阅读指南宝塔与 1Panel
面板 PHP 可以完全独立于系统 PHP。列出所有版本并映射各站点运行时，从可信面板更新渠道获取含两个 CVE 修复的包或镜像。面板更新不等于 PHP 更新。重启每个受影响服务或重建容器，切换站点处理器后逐站验证。不同面板版本的菜单名称可能不同。
阅读指南WordPress、虚拟主机与托管服务
更新 WordPress、Drupal 或 Joomla 不会更新 PHP。向主机商索取实际处理器、完整包修订、两个 CVE 的修复说明和进程重启凭据。面板中的同一分支可能对应不同构建。托管云服务或一体化设备应按产品厂商公告更新，不要自行替换捆绑运行时。
阅读指南