▌事件背景

2026 年 10 月 20 日，公开渠道出现匿名披露帖，称 PHP 存在两处远程代码执行漏洞，原定于 10 月 22 日协调披露。该帖随后被删除，但相关内容已在社交平台扩散。

同日，安全研究机构对外确认漏洞真实存在，编号为 CVE-2026-109618、CVE-2026-109619，并表示已完成其中 CVE-2026-109618 的复现。

随后 PHP 官方发布安全更新预告，明确修复版本发布时间为 2026 年 10 月 21 日 14:00 UTC（北京时间 22:00），两处漏洞官方评级均为 CVSS v4.0 9.2。公告中另有一句不常见的表述：若漏洞细节被公开、或出现野外利用证据，官方保留提前发布的权利。

▌漏洞基本信息

图 1　检索 app="WordPress"，返回 72,260,260 条匹配记录（3,103,937 条独立 IP），为演示涉及应用中体量最大者

另有国内使用量较大的两款 PHP 应用，虽未出现在当前演示列表中，但同属 PHP 应用范畴，是否存在同类风险需待官方公告确认，建议一并纳入排查：

图 2　检索 app="ThinkPHP" && country="CN"，国内返回 443,587 条匹配记录（49,252 条独立 IP）

▌影响版本

公开泄露信息称 PHP 5 及之后版本均可能受影响，该范围尚未获得官方确认），将在修复版本发布时一并公布。结合现有公开信息，当前可确认与待确认的内容如下：

三点说明：

其一，安全研究团队对外表述为影响 PHP 5、6、7、8 各版本，此为第三方判断，官方公告未予确认。

其二，另有安全研究员公开判断是仅 PHP 8 分支会获得补丁，这与 PHP 5、7 早已终止维护的现状一致。

其三，流传演示环境为 Ubuntu 26.04 + PHP 8.5.4，该版本信息未经官方证实。

综合来看，可获得官方修复的分支为 8.2 至 8.5。其余分支不存在「等待补丁」这一选项，风险将长期存在，唯一可行路径是升级至受支持分支。

▌补丁发布前的处置建议

距修复版本发布尚有一段时间，以下工作建议在今晚 22:00 前完成，以保证补丁释出后可立即进入实施阶段。

1. 完成 PHP 资产清点。 清点范围不应局限于 Web 站点。CLI 脚本、定时任务、常驻队列进程、后台管理面板往往运行着不同版本的 PHP，需逐一登记版本号与部署位置。

2. 确认每台实例的安装来源。 区分系统发行版源、主机面板集成、第三方软件源、容器镜像与自行编译五种来源。来源决定了补丁的获取路径与回滚方式，需在补丁发布前明确。

3. 核对面板环境。 使用宝塔、Plesk 等主机面板的环境，系统级 PHP 与面板托管的 PHP 属于两套独立安装，须逐一核对站点绑定的 PHP handler，避免仅升级其中之一。

4. 梳理 EOL 分支资产并排定迁移计划。 仍在运行 PHP 8.1 及更早版本、尤其 7.4 与 5.6 的业务，本次不会获得官方修复。需在补丁发布前明确两项决定：是否排期升级至受支持分支，以及升级完成前的风险隔离方式。

5. 收敛暴露面。 CERT-EU 的建议同样适用于此阶段：对短期内无法完成修补的对外应用，考虑先从公网撤除，或通过访问控制限制来源。

6. 开启并留存日志。 重点采集 Web 访问日志与 PHP-FPM 运行日志，关注由 Web 服务用户发起的异常子进程创建、异常命令执行与可疑请求特征。

7. 完成变更准备。 提前完成变更审批、备份与回滚预案，明确值守人员与通知链路，确保 22:00 修复版本释出后可立即执行升级，而非次日再走流程。

▌修复指南

1.确认受影响版本

修复版本发布后，首先以官方公告公布的受影响版本范围与触发条件为准，核对自身资产是否存在可被利用的路径。在确认之前不建议直接对全网实例执行升级。

2.获取修复版本

仅从官方渠道获取：php.net 下载页、各 Linux 发行版安全源、容器镜像的官方仓库。参考 9 月 24 日发布的 8.5.11、8.4.26、8.3.35、8.2.34，本次修复版本预计落在 8.2 至 8.5 四条分支，具体版本号以公告为准。

3.执行升级

按「先测试、再灰度、后全量」的顺序推进。升级前确认已具备回滚条件，包括旧版本安装包、配置文件与数据备份。

4.重启相关进程

这一步最容易被跳过，也是最容易导致「已修复」判断失真的环节。二进制包更新后，内存中运行的仍是旧版本代码：

• Apache mod_php 方式：重启 Apache 服务
• PHP-FPM 方式：重启对应的 FPM 进程池
• 常驻 CLI 进程（队列 Worker、守护脚本）：逐一重启

不可仅凭 php -v 的输出判断修复已完成，该命令反映的是命令行二进制的版本，与正在提供服务的进程无关。

5.更新容器镜像

容器环境仅重启容器无法完成修复，必须重新构建包含新版本 PHP 的镜像，并执行全量滚动更新，确认所有副本均已切换至新镜像后，再回收旧副本。

6.修复后核验

核验内容包括三项：实际运行进程所加载的 PHP 版本、业务功能回归结果、以及修复前登记的资产清单是否全部覆盖。存在遗漏实例时，应作为遗留风险单独登记。

7.无法升级分支的补偿措施

对 PHP 8.1 及更早、不会获得官方修复的实例，若确实无法在短期内完成升级，可采取以下措施降低风险。需要明确的是，这些措施只能降低被利用的可能性，不能消除漏洞：

• 将实例从公网撤除，或通过 VPN、零信任网关限制访问来源
• 在 WAF 侧启用虚拟补丁与异常请求拦截规则
• 以最小权限用户运行 Web 服务，限制可写入目录范围
• 关闭非必要的扩展与模块，减少暴露面

8.关于常见无效措施

disable_functions、open_basedir 属于 PHP 脚本层安全限制。本次漏洞位于解释器原生代码层，在进入函数调用之前执行流即被劫持，此类配置无法形成有效防护。

封禁 SSH 端口与攻击链路无关，漏洞入口为 80/443 等 Web 端口。

常规 WAF 规则对新漏洞缺乏覆盖，仅可作为辅助手段，不宜作为核心防护依赖。

▌参考

• https://www.php.net/archive/2026.php
• https://cert.europa.eu/publications/security-advisories/2026-018/
• https://x.com/watchtowrcyber
• https://www.bleepingcomputer.com/news/security/php-warns-admins-of-two-critical-flaws-emergency-patches-coming-tomorrow/