PHP 官方于 2026 年 10 月 21 日发布安全更新，修复 CVE-2026-109618 与 CVE-2026-109619。官方表示，两项漏洞可能造成未经身份验证的远程代码执行；也就是说，攻击者不一定需要网站账号，便可能设法在脆弱服务器上执行恶意代码。英国国家网络安全中心（NCSC）和欧盟网络安全局（ENISA）均建议组织立即盘点暴露在公网的 PHP 应用并优先更新。PHP 官方安全公告｜NCSC 指引｜ENISA 联合警报
这不是只与“自己写 PHP 代码”的团队有关的消息。WordPress、部分商业建站系统和托管服务也依赖 PHP 运行时：即使 WordPress 核心、主题和插件都已更新，只要底层 PHP 解释器仍未取得修复，网站仍需由主机商或运维团队确认处置状态。
已确认的漏洞与受影响部署
PHP 官方将这两项问题描述为严重的远程代码执行风险：
- CVE-2026-109618： PHP 在内存不足（OOM）处理期间，可能在内部请求数据尚未完整初始化时被中断，后续清理过程可能把无效数据当作有效数据处理。
- CVE-2026-109619： 某个请求所属的内部状态在其支撑内存释放后仍可能残留；同一工作进程处理后续请求时，可能在正常初始化重置前使用该过期状态。
官方明确指出，所有处理 Web 请求的 PHP 安装都应纳入排查，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed；其中 Apache mod_php 的风险最高，官方已确认存在无需应用代码先执行即可触发的攻击场景。这一事实意味着仅检查某个业务接口的鉴权、或仅升级应用依赖，并不能替代 PHP 运行时补丁。
需要优先盘点的攻击面
以下是防守方应优先确认的暴露面，并非漏洞利用教程：
对公网提供服务的 PHP 请求入口
优先列出所有可从互联网访问、最终由 PHP 处理的站点、子域、管理后台、API、表单、上传和导入功能。重点不在于某个 URL 是否看起来敏感，而在于它是否会进入未修复的 PHP Web 运行时。NCSC 同样建议先识别基础设施中运行 PHP 的系统，并优先处理互联网暴露系统。
Apache mod_php 与长生命周期工作进程
PHP 官方将 mod_php 列为风险最高的配置之一。对于其他 PHP SAPI，也不应因架构不同而排除风险：官方列出的 PHP-FPM、CGI、FrankenPHP 与 LiteSpeed 均应核对实际版本、补丁来源和重启状态。应将每个环境的 Web 服务器、PHP SAPI、PHP 二进制版本和承载应用一并登记，避免只在命令行检查到一个版本，却遗漏实际处理流量的另一个运行时。
商业站点中的高价值数据与权限
如果远程代码执行成功，攻击者实际能触及的范围取决于 Web 服务进程权限、文件权限、网络分段、密钥管理和云账号权限。对商业 WordPress 或 PHP 站点，应优先保护订单与客户资料、会员数据、支付或物流集成密钥、邮件服务凭据、对象存储凭据、备份文件和管理账号会话。这里列出的是成功入侵后可能被波及的资产类别，不代表每个站点都会发生全部后果。
远程代码执行可能造成的业务影响
“远程代码执行”不是单一事件，而是攻击者获得服务器进程执行能力后可能引发的一系列风险。影响程度取决于该进程权限与环境隔离情况，常见后果包括：
- 数据泄露或篡改： 读取配置文件、环境变量和数据库连接信息，进而访问业务数据；也可能改写页面、订单状态或后台内容。
- 持久化控制： 在可写目录、计划任务、启动配置或应用文件中留下后门，使一次修复后仍可能被再次进入。
- 业务中断： 篡改应用逻辑、消耗资源、破坏文件或触发站点不可用，影响获客、下单和客户服务。
- 横向风险： 若 Web 进程能访问内部服务、共享存储或云环境凭据，影响可能扩大到同一网络或账户边界内的其他系统。
这些属于安全响应中需要验证和控制的后果，而不是对已发生攻击的判断。若补丁延迟或发现异常，应在升级前后保留日志与证据，并根据自身能力进行入侵排查。
修复版本、旧版本与托管环境
PHP 官方发布的修复版本为：
| PHP 分支 | 已修复版本 |
|---|---|
| 8.5 | 8.5.12 |
| 8.4 | 8.4.27 |
| 8.3 | 8.3.36 |
| 8.2 | 8.2.35 |
PHP 8.1 及更早版本已经不再获得 PHP 项目的常规上游更新。官方表示，部分 Linux 发行版和长期支持（LTS）供应商可能提供回补；因此，使用旧版本的团队不能只看主版本号判断安全性，而应向发行版、镜像维护方或托管商取得“已回补这两个 CVE”的明确确认。PHP 安全团队也为 7.4、8.0 和 8.1 提供了最小化源码回补，供自行构建或无法使用 LTS 供应商补丁的人参考；这不等于所有托管环境已经自动修复。
对于托管 WordPress，站长通常无法直接控制系统包。应向服务商确认四件事：正在服务该站点的 PHP 版本与 SAPI、补丁是否已包含这两个 CVE、完成升级与重启的时间、以及无法即时更新时是否已隔离公网暴露。不要将“WordPress 已更新”或“控制台显示 PHP 8.x”视为补丁完成的证据。
PHP 开发团队的优先处置清单
立即完成资产发现
盘点生产、灾备、预发布、运维后台、旧子站和第三方设备中的 PHP。记录每个系统的公网可达性、实际处理请求的 SAPI、版本、包来源、业务负责人和修复窗口。不要只检查容器镜像或 CI 构建记录；应以正在承接流量的运行实例为准。
以升级和重启作为完成标准
将运行时升级到对应分支的修复版本，并按变更流程验证 Web 服务与 PHP 工作进程已加载新版本。升级后进行最小必要的业务验证，例如关键页面、登录、表单、上传、订单或 API 的健康检查。PHP 官方强调，临时缓解措施无法构成完整解决方案；完成升级才是主要目标。
复核权限与异常迹象
检查 Web 服务账号对应用目录、密钥文件、备份目录和内部网络的访问范围，收紧不必要的写入与横向访问权限。对补丁前存在公网暴露的系统，结合 Web、PHP、主机与身份日志查看异常请求、异常进程、异常文件变更和未知管理账号。NCSC 也建议在无法立即升级或下线时，评估是否已有受损证据及后门。
WordPress 商业站点的专项检查
将运行时修复纳入业务应急流程
WordPress 依赖 PHP 解释器执行。对电商、预约、会员、广告落地页、B2B 获客和内容变现站点而言，底层 PHP 漏洞应与支付、客户数据和可用性风险一起评估。站点负责人应立即通知主机商、运维或外包方，而不是只安排 WordPress 管理员更新插件。
优先保护交易与客户数据链路
明确哪些站点负责收集表单、创建订单、处理会员、发送交易邮件或连接支付与 CRM。确认这些站点的备份可用、管理员账号最小化、密钥没有放在可公开下载的目录，并对关键集成做好凭据轮换预案。若怀疑已被入侵，应遵循内部事件响应流程，避免在未经调查的情况下仅删除可疑文件后继续运行。
与托管商取得可核验的状态
商业站点应要求服务商提供可核验的信息，而非笼统回复“已加固”：受影响 PHP 运行时的版本、具体修补状态、升级重启是否完成、同账户其他站点是否也已排查，以及待修复期间的访问隔离措施。ENISA 也建议组织识别 PHP 应用、与托管和服务提供方协调，并优先处置互联网暴露系统。
无法立即升级时的风险收敛
官方提供了一些临时缓解思路，例如限制特定请求资源、调整部分 PHP 配置以及重启工作进程，但 PHP 明确说明：这些做法只能降低某些攻击路径的暴露，不能使系统恢复安全状态。因此，实施任何临时配置前应在自己的环境中评估业务影响，并把升级列为不可替代的后续动作。
若无法在可接受时间内完成补丁、临时措施也难以及时验证，NCSC 与 ENISA 都建议考虑将对外暴露的应用从公网隔离，直至能够完成修复。隔离会影响业务，因此应由业务、运维和安全负责人共同确定范围；但对于承载客户数据或交易的高价值站点，延迟修复本身也应被视为明确的业务风险。
48 小时应急顺序
- 0–4 小时： 建立 PHP 资产清单，先标记公网暴露、
mod_php和承载商业交易的实例。 - 4–24 小时： 升级到相应修复版本，重启实际承接请求的服务与工作进程，并完成关键业务验证。
- 24–48 小时： 向托管商和第三方软件供应商追踪补丁状态；复核日志、可写目录、管理账号与关键凭据，必要时启动事件响应。
- 持续进行： 为不受上游支持的旧分支制定迁移或发行版回补验证计划，避免下一次严重漏洞仍被旧版本阻塞。
