如果你的网站跑在 PHP 上，10 月 21 日这轮安全更新值得尽快安排。PHP 官方一次修复了两处可能导致未授权远程代码执行的问题，编号是 CVE-2026-109618 和 CVE-2026-109619。对站长来说，现在最需要弄清楚的是：网站实际用了哪个版本，修复包有没有装到它身上。
本文依据截至 2026 年 10 月 22 日可查的官方公告整理，侧重排查和更新，不包含漏洞利用代码。查看 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 |
版本号之外还有一种情况：发行版或商业维护方把补丁回移到了自己的软件包中。这时应对照供应商的安全公告、软件包修订号确认，不能只凭一段上游版本号判断。托管在别人的服务器上，也可以直接让服务商确认这两个 CVE 是否已修复。ENISA 的联合通告同样建议先清点 PHP 应用，再协调服务商安装更新，优先处理面向公网的系统。
两处漏洞，大致出了什么问题
CVE-2026-109618 与内存耗尽时的清理过程有关。可以把它理解为：某些内部数据还没有准备完整，请求就因为内存不足被打断；后续清理却可能继续使用这些不完整的数据，造成内存损坏。这里的“内存不足”不只是网站变慢那么简单。具体技术说明见 PHP 项目的 OOM 公告。
CVE-2026-109619 与跨请求残留的内部状态有关。处理完一个请求后，工作进程里可能还留着指向已释放内存的状态；同一个进程接到后续请求，又在正常初始化完成前访问它，就可能出问题。它和前一个漏洞有关联，但不是换了一个编号的同一个问题。详情见 PHP 项目的状态残留公告。
不同运行方式的触发条件并不完全一样。PHP 官方把提供 Web 请求服务的 PHP 安装列为需要关注的范围，包括 PHP-FPM、Apache mod_php 等。因此，使用 Nginx 加 PHP-FPM 的站点也应核对并更新，不能因为没有使用 Apache 就跳过。
用宝塔管理网站，建议按这个顺序检查
1. 查网站实际使用的 PHP
先在站点设置里查看它选择的 PHP 分支，再核对对应组件的完整版本。一台服务器装着多个 PHP 版本时，更新其中一个，并不能说明所有网站都完成了更新。
有终端权限的话，可以辅助查看某个 PHP 可执行文件。例如，下面查看的是宝塔常见安装路径下的 PHP 8.2 命令行版本：
/www/server/php/82/bin/php -v但这条命令只能说明它自身的版本。网站请求由哪个 PHP-FPM 实例处理，仍要结合站点配置确认。PHP 文档区分了 CLI 与 Web 运行接口；需要在受保护的运维页面核实时，可以结合 PHP_VERSION 和 PHP_SAPI 查看。检查结束后清理临时诊断页面，避免把完整环境信息长期公开。
2. 备份后，安装对应分支的修复更新
建议先确认数据库和站点文件的备份可用，再通过宝塔相应 PHP 组件、系统发行版或服务商提供的渠道更新。对仍受支持的分支，可以优先安排同分支修复；跨大版本迁移则另外做兼容性验证。
更新后确认实际提供服务的 PHP 工作进程已加载新版本。别只看面板里显示安装完成，网站绑定的实例和运行中的进程也需要核对。
3. 跑一遍关键业务
首页能打开只是第一步。可以按自己站点的实际功能检查登录、文章读取、表单和上传，再按既有测试流程验证订单查询、支付回调或异步任务。同时查看 PHP 与 Web 服务日志，关注更新后新增的错误。交易类站点应使用测试环境或既有安全验证方法，避免为了检查更新产生不必要的真实交易。
暂时更新不了，要注意什么
PHP 官方给出了一些针对特定触发路径的临时措施，但也明确说明：这些措施不能让未修复的安装变得安全，完整解决仍然依赖更新。对于当前无法维护的公网应用，可以先与运维或服务商商量隔离措施，再尽快安排修复，不宜把一份通用的配置片段直接当成补丁。
还在使用 PHP 8.1 或更早分支的站点，需要单独确认维护来源。它们已不在 PHP 项目的正常支持范围内；第三方回移补丁不等同于恢复官方持续支持。PHP 8.2 的安全支持也将在 2026 年 12 月 31 日结束，完成眼前这次修复后，值得留出时间规划后续迁移。具体周期以 PHP 官方支持版本表为准。
如果今天只做一件事，就把站点、PHP 实例和修复版本对应起来。弄清楚“哪个网站用了哪个 PHP”，后面的更新和复查才不会漏掉一处。