PHP 爆出两个高危安全漏洞！CVE-2026-109618、CVE-2026-109619 修复方案与防护指南

PHP 爆出两个高危安全漏洞！CVE-2026-109618、CVE-2026-109619 修复方案与防护指南

一、前言：为什么 PHP 安全漏洞值得高度关注？

2026 年 10 月 21 日，PHP 官方发布了多个安全更新，修复了两个可能导致远程代码执行的严重漏洞。

这两个漏洞分别为：

• CVE-2026-109618

• CVE-2026-109619

根据 PHP 官方安全公告，这两个漏洞的 CVSS v4.0 评分均为 9.2，属于严重级别。

在满足特定条件时，攻击者可能无需身份验证，就能通过构造恶意请求触发漏洞，进而在受影响的服务器上执行任意代码。

这意味着，问题不一定出在我们自己编写的 PHP 业务代码中，也可能来自 PHP 运行时本身。

对于运行 PHP 网站、电商系统、企业官网、内容管理系统以及 API 服务的团队来说，这类漏洞尤其值得重视。

如果服务器运行的是受影响的 PHP 版本，即使业务代码没有明显漏洞，也不能因此认为系统就是安全的。

本文将从漏洞发布时间、漏洞原理、受影响版本、修复步骤和长期防护策略几个方面进行分析，帮助开发者和运维人员建立一套可执行的安全处理流程。

安全提醒：本文以 PHP 官方公告及相关安全机构发布的信息为依据。漏洞版本、修复版本和部署方式可能存在差异，实际操作前请核对 PHP 官方公告以及所使用的操作系统、容器镜像或托管服务商的安全通知。

二、PHP 安全漏洞的时间线

了解漏洞的发现、披露和修复时间，有助于判断当前系统应该采取什么措施。

1. 2024 年：相关内存处理问题开始进入研究视野

根据 PHP Foundation 于 2026 年 10 月 21 日发布的说明，PHP 安全团队在 2024 年处理其他安全问题时，已经注意到与内存耗尽处理有关的潜在问题。

当时，相关研究尚未明确形成可实际利用的完整攻击路径。

这也说明，安全漏洞的生命周期可能相当长：一个看似局部的底层问题，经过进一步研究后，可能被证明具有更严重的安全影响。

2. 2026 年 8 月至 9 月：研究人员进一步验证风险

PHP Foundation 的后续说明提到，2026 年，多家安全研究团队继续研究和验证相关问题。

研究人员逐步明确了相关缺陷的攻击路径及其潜在影响。

对于基础运行时软件而言，这类研究不仅需要发现问题，还需要判断问题能否在真实运行环境中被触发，以及修复是否会引入兼容性或稳定性风险。

3. 2026 年 10 月 20 日：PHP 官方发布安全更新预告

2026 年 10 月 20 日，PHP 安全团队提前发布通知，表示即将推出一次重要的安全更新。

官方指出，此次更新将处理两个严重漏洞，两个漏洞的 CVSS v4.0 评分均为 9.2。

这意味着使用 PHP 的组织和开发者应当提前盘点服务器、确认部署方式，并为更新做好准备。

4. 2026 年 10 月 21 日：修复版本正式发布

2026 年 10 月 21 日，PHP 官方发布了修复版本。

本次涉及的两个漏洞分别为：

• CVE-2026-109618：与内存耗尽处理过程中的内存状态异常有关。

• CVE-2026-109619：与请求处理过程中失效的全局状态有关。

两个漏洞在特定条件下均可能导致远程代码执行。

官方发布了多个维护分支的修复版本，建议受影响的用户立即升级。

时间线总结

时间	关键事件	对开发者的意义
2024 年	相关内存处理问题进入研究视野	底层缺陷可能需要较长时间才能明确风险
2026 年 8---9 月	研究人员进一步验证攻击路径	安全研究需要结合实际运行环境
2026 年 10 月 20 日	PHP 官方发布更新预告	提前盘点资产并准备升级
2026 年 10 月 21 日	PHP 官方发布安全修复版本	立即核对版本并执行修复

参考资料：

PHP 官方安全公告：

PHP: News Archive - 2026

PHP Foundation 漏洞说明：

Today's PHP Security Release, and How We're Strengthening PHP Security --- The PHP Foundation --- Supporting, Advancing, and Developing the PHP Language

三、这两个 PHP 漏洞究竟是什么？

在讨论漏洞之前，需要先理解一个基本概念。

PHP 不仅仅是一门编程语言，它还包含负责解析请求、管理内存、执行脚本和维护运行状态的底层运行时组件。

即使应用程序的业务代码没有明显问题，只要运行时本身存在安全缺陷，整个应用仍然可能受到影响。

1. CVE-2026-109618：内存耗尽处理过程中的异常

这个漏洞与内存耗尽，也就是 Out Of Memory（OOM）处理过程有关。

PHP 在执行请求时，需要不断分配和释放内存。

当内存使用达到限制，或者内部操作发生异常时，运行时必须按照正确的流程退出当前处理过程，并确保内部数据处于一致状态。

如果异常处理过程中，某些内部数据没有被正确初始化或清理，后续逻辑就可能错误地使用这些数据。

这种内存状态异常在特定条件下可能演变成严重的安全问题。

对于受影响的 PHP 版本，攻击者可能通过构造特定请求触发相关路径，最终导致远程代码执行。

需要注意的是，这并不意味着任何普通的内存不足错误都会导致服务器被入侵。漏洞利用依赖具体的运行条件和内部处理路径。

2. CVE-2026-109619：失效的全局状态问题

第二个漏洞与请求处理期间的内部状态管理有关。

在 PHP 的运行过程中，部分内部状态可能引用当前请求使用的内存。

正常情况下，当请求结束、相关内存被释放后，运行时应该确保这些状态不再指向已经失效的内存区域。

如果某些状态没有被正确重置，后续请求就可能访问已经释放的内存，或者在内部状态重新初始化之前使用过期数据。

这类问题属于典型的内存生命周期管理缺陷。

在满足特定条件时，攻击者可能利用它造成内存状态异常，进一步影响程序执行。

3. 两个漏洞的共同风险

这两个漏洞的共同点是：问题位于 PHP 运行时底层，而不是某个具体的业务接口。

因此，不能简单地认为只要给登录接口加上验证码、限制上传文件类型，或者修改一段业务代码，就可以彻底解决问题。

如果服务器使用的是受影响版本，正确的处理方式仍然是升级到包含官方修复的版本。

四、哪些 PHP 版本受到影响？

根据 PHP 官方安全公告及相关安全机构的修复说明，以下是本次漏洞的主要修复版本。

PHP 分支	修复版本	处理建议
PHP 8.5.x	8.5.12	升级至 8.5.12 或更高的适用修复版本
PHP 8.4.x	8.4.27	升级至 8.4.27 或更高的适用修复版本
PHP 8.3.x	8.3.36	升级至 8.3.36 或更高的适用修复版本
PHP 8.2.x	8.2.35	升级至 8.2.35 或更高的适用修复版本
PHP 8.1 及更早版本	已停止官方常规安全支持	尽快迁移至受支持版本

这里有两个需要特别注意的问题。

第一，PHP 8.1 及更早版本不能简单地通过安装一个普通更新来解决问题。

这些版本已经退出 PHP 官方常规安全支持。部分操作系统发行版或商业服务商可能提供回移补丁，但必须核实具体的软件包及补丁状态。

第二，不要只看 PHP 主版本号。

例如，PHP 8.4.20 与 PHP 8.4.27 虽然都属于 8.4 分支，但并不意味着它们具有相同的安全修复状态。

判断是否安全，应当检查完整版本号、实际运行的二进制文件以及发行版的补丁记录。

版本信息以 PHP 官方公告为准：

PHP: News Archive - 2026

五、如何检查自己的服务器是否存在风险？

在升级之前，建议先完成资产盘点。

1. 查看 PHP 命令行版本

在 Linux 服务器上执行：

php -v

如果返回：

PHP 8.4.26 (cli)

说明当前命令行环境运行的是 PHP 8.4.26。

该版本低于本次公告中 PHP 8.4 分支的修复版本，因此需要进一步检查并升级。

但必须注意：命令行使用的 PHP 版本，不一定等于网站实际使用的版本。

例如，服务器可能同时安装了多个 PHP 版本，也可能由 PHP-FPM、Apache 模块或容器单独提供运行环境。

2. 查看 PHP-FPM 版本

如果网站使用 PHP-FPM，可以先检查相关进程：

ps aux | grep '[p]hp-fpm'

然后查看对应服务的配置、启动路径和软件包信息。

在 systemd 环境中，可以尝试：

systemctl status php-fpm

不同 Linux 发行版可能使用不同的服务名称，例如：

systemctl status php8.4-fpm

实际服务名需要根据服务器安装情况确定。

如果网站使用 Apache 的 mod_php、php-cgi、LiteSpeed、FrankenPHP 或容器部署，还需要检查对应的运行环境，不能只检查 PHP-FPM。

3. 查看网站实际运行的 PHP 版本

对于无法确认运行环境的网站，可以通过服务器管理权限或受控的诊断页面检查实际运行版本。

如果使用 PHP 脚本诊断：

<?php

echo PHP_VERSION;

建议仅在受控环境中使用，并确保诊断页面不会向公众暴露。

检查完成后，应立即删除临时诊断文件。

不建议长期部署包含完整服务器信息的 phpinfo() 页面，因为它可能暴露扩展、路径、配置等敏感信息。

4. 盘点所有 PHP 运行环境

除了主网站，还需要检查：

• 测试环境和预发布环境。

• 旧版网站及历史业务系统。

• Docker 容器和 Kubernetes 工作负载。

• WordPress、Drupal、Joomla 等内容管理系统。

• 使用 PHP 的第三方软件和设备。

• 通过定时任务运行的 PHP 脚本。

• 云服务器、虚拟主机和托管平台上的 PHP 实例。

真正有效的安全排查，不是确认一台服务器是否安全，而是确认所有相关运行环境是否已经完成修复。

六、如何修复 PHP 安全漏洞？

修复的核心原则是：优先使用官方或受信任的软件发行渠道，将 PHP 更新至包含对应安全补丁的版本。

升级之前，应当先确认业务兼容性、备份状态和回滚方案。

1. 修复前做好准备

建议先完成以下工作：

1. 记录当前 PHP 版本。

2. 确认网站使用的 PHP 运行方式。

3. 备份数据库、网站文件和关键配置。

4. 确认当前 PHP 扩展及依赖。

5. 在测试环境验证应用兼容性。

6. 准备维护窗口和回滚方案。

如果服务器已经出现异常进程、可疑文件或其他入侵迹象，应当同时启动安全事件响应流程，不能把升级视为唯一的处理措施。

2. Ubuntu 或 Debian 环境

如果 PHP 来自 Ubuntu 或 Debian 官方软件仓库，首先检查系统的软件包更新：

sudo apt update

然后检查 PHP 相关软件包：

apt list --upgradable 2>/dev/null | grep -E 'php|libapache2-mod-php'

确认软件包来源、目标版本和依赖关系后，再根据实际安装情况执行更新。

例如：

sudo apt upgrade

需要特别注意：上述命令会更新系统中符合升级条件的软件包，并不保证一定安装指定的 PHP 修复版本。

如果发行版尚未提供相应补丁，或者使用了第三方 PHP 软件源，就需要进一步确认软件包的维护状态。

不要为了追求版本号而随意切换软件源，也不要在生产服务器上未经评估就执行大规模系统升级。

3. 使用 Docker 部署 PHP

如果 PHP 运行在 Docker 容器中，应当检查 Dockerfile 和镜像标签。

例如，原来的镜像可能是：

FROM php:8.4.26-fpm

应当根据官方镜像仓库中实际可用的修复镜像，更新至包含对应补丁的版本。

概念上可以修改为：

FROM php:8.4.27-fpm

这里的标签仅用于说明升级思路，实际使用时需要确认该标签存在，并选择适合当前业务和部署架构的镜像。

修改 Dockerfile 后，还需要重新构建并部署镜像。

例如：

docker build -t my-php-app:security-patched .

随后应当按照现有的部署流程发布新镜像。

需要注意：

• 仅修改 Dockerfile 不代表正在运行的容器已经更新。

• 重建镜像后，需要确认新容器确实使用了修复版本。

• 如果使用了固定摘要的镜像引用，还需要更新对应的镜像摘要。

• 应当检查基础镜像中的 PHP 版本及相关扩展。

• 不建议为了方便而直接使用未经验证的 latest 标签。

生产环境还应保留旧版本镜像和回滚方案，但不能长期继续对外运行存在已知高危漏洞的旧容器。

4. Windows 环境

如果 PHP 部署在 Windows 服务器上，应当从 PHP 官方下载页面或可信的发行渠道获取适用版本。

官方地址：

PHP: Downloads

升级时需要确认：

• PHP 版本及架构是否匹配。

• Apache 或 IIS 的集成方式。

• 所需扩展是否兼容。

• php.ini 中的配置是否需要迁移。

• 网站在测试环境中能否正常运行。

完成替换后，按照部署方式重启对应服务，并验证实际运行版本。

5. 宝塔面板及其他服务器管理面板

如果使用宝塔面板或其他服务器管理工具，可以通过面板提供的 PHP 版本管理和更新功能进行升级。

具体步骤可能因面板版本、软件源和部署方式不同而有所差异。

建议按照以下顺序操作：

1. 确认网站绑定的 PHP 版本。

2. 备份网站文件及配置。

3. 检查目标 PHP 版本是否包含修复补丁。

4. 安装或升级对应版本。

5. 检查 PHP 扩展和配置。

6. 将网站切换至修复后的运行环境。

7. 重启或重新加载相关服务。

8. 验证网站和后台功能。

9. 确认实际运行的 PHP 版本已经更新。

如果面板暂时没有提供修复版本，不应假设旧版本已经安全。应联系面板服务商或软件包维护方，确认补丁计划和可用的升级方案。

七、升级之后，还需要做什么？

很多团队完成升级后，就认为安全工作已经结束。

实际上，升级只解决了漏洞修复问题，并不能证明服务器此前没有被攻击。

对于严重的远程代码执行漏洞，建议在更新后开展一次针对性的安全检查。

1. 检查 Web 访问日志

重点关注：

• 异常的请求频率。

• 非正常的请求大小。

• 大量返回 500 错误的请求。

• 不符合业务规律的请求模式。

• 可疑的外部请求和访问来源。

需要注意，日志异常不一定意味着攻击成功，正常业务也可能产生大量错误。

分析时应结合时间、请求路径、进程日志和服务器其他证据综合判断。

2. 检查服务器是否出现异常进程

在 Linux 环境中，可以查看进程：

ps aux --sort=-%cpu | head -n 20

查看近期系统日志：

journalctl --since "24 hours ago"

如果发现无法解释的高 CPU 占用、异常子进程、可疑外联或不明程序，应进一步调查。

以上命令只能帮助发现部分异常，不能替代专业的入侵检测和事件响应。

3. 检查可疑文件和持久化行为

如果怀疑服务器已经受到攻击，应重点检查：

• 网站目录中新增或被修改的文件。

• PHP 文件中异常的代码变更。

• 计划任务和启动脚本。

• 新增的系统账户和 SSH 密钥。

• Web 服务账户的权限变化。

• 未经授权的外联行为。

• 数据库账户及其他敏感凭据的使用情况。

如果确认存在入侵迹象，应保存日志和必要的证据，隔离受影响的主机，并按照安全事件响应流程处理。

在确认攻击范围之前，不建议直接删除所有可疑文件，因为这可能破坏后续调查所需的证据。

4. 必要时轮换凭据

如果有证据表明攻击者可能访问过服务器或应用程序的敏感数据，应根据实际影响评估是否需要轮换：

• 数据库账户密码。

• 云平台访问密钥。

• 应用程序密钥。

• API Token。

• SSH 密钥及其他身份凭据。

凭据轮换应在受控环境中执行，并检查旧凭据是否仍然有效。

如果服务器已经被攻陷，仅修改密码而不处理攻击者可能建立的持久化访问方式，风险仍然存在。

八、除了修复本次漏洞，PHP 项目还应该如何防护？

本次漏洞提醒我们，应用安全不仅取决于开发人员写了什么代码，也取决于底层运行环境是否及时更新。

对于长期运行的 PHP 项目，建议建立以下安全机制。

1. 建立 PHP 版本生命周期管理机制

PHP 各版本都有明确的支持周期。

官方通常为新分支提供约两年的主动维护支持，之后进入仅修复严重安全问题的阶段，最终停止官方支持。

因此，项目不能一直停留在最初上线时的 PHP 版本。

建议建立版本台账，至少记录：

• 项目名称。

• 运行环境。

• PHP 完整版本号。

• 版本支持截止时间。

• 使用的扩展。

• 依赖软件包。

• 负责人。

• 最近一次安全检查时间。

同时，制定明确的升级策略。

例如：

• 每周检查一次 PHP 安全公告。

• 对严重漏洞立即开展影响评估。

• 对需要紧急修复的漏洞安排加急变更。

• 对即将停止支持的版本提前制定迁移计划。

• 在测试环境完成兼容性验证后再发布生产版本。

这里的关键不是机械地追求最新版本，而是确保使用受支持、已修复且适合当前业务的版本。

2. 对外部输入进行严格校验

PHP 应用经常处理表单、URL 参数、上传文件、API 请求和数据库数据。

所有外部输入都应被视为不可信数据。

例如，在处理用户输入时：

• 对数据类型进行检查。

• 对长度和取值范围进行限制。

• 对文件上传进行格式、大小和内容检查。

• 避免将用户输入直接拼接进 SQL。

• 不要把未经验证的数据直接交给敏感函数执行。

输入校验不能代替底层安全补丁，但它可以降低其他类型漏洞的风险。

3. 防止 SQL 注入

不安全的 SQL 拼接可能导致数据库被非法读取或修改。

例如，不推荐直接把用户输入拼接到 SQL 语句中。

应优先使用 PDO 预处理语句：

<?php

$pdo = new PDO(
    'mysql:host=localhost;dbname=app;charset=utf8mb4',
    $dbUser,
    $dbPassword
);

$stmt = $pdo->prepare(
    'SELECT id, username FROM users WHERE username = :username'
);

$stmt->execute([
    'username' => $username
]);

$user = $stmt->fetch(PDO::FETCH_ASSOC);

示例中的 $dbUser、$dbPassword 和 $username 应由应用程序按照实际情况提供。

数据库凭据不应硬编码在公开仓库中。

使用预处理语句，可以降低 SQL 注入风险，但仍然需要正确处理数据库权限、动态表名和其他 SQL 结构。

4. 谨慎处理文件上传

文件上传是 Web 应用中需要重点保护的功能之一。

建议至少做到：

• 限制文件大小。

• 验证允许的文件类型。

• 检查文件内容，而不只是扩展名。

• 使用随机文件名。

• 将上传文件存放在非执行目录。

• 禁止上传目录执行 PHP 等脚本。

• 限制 Web 服务账户对文件系统的写入权限。

• 对高风险业务增加文件扫描机制。

例如，不能仅凭文件名以 .jpg 结尾，就认定它是安全图片。

同时，也不应把任何一种文件检查方式当作绝对可靠的安全边界。

5. 合理配置 PHP 生产环境

生产环境应避免向普通用户暴露详细错误信息。

例如，可以检查以下配置：

display_errors = Off
log_errors = On
expose_php = Off

这些配置可以降低部分信息泄露风险。

但它们不能修复 PHP 核心漏洞，也不能替代系统更新。

具体配置还应根据业务的日志收集方式、故障排查要求和部署环境进行调整。

6. 最小权限原则

即使应用程序出现漏洞，也应尽可能限制攻击者能够造成的影响。

建议：

• PHP 进程使用专用的低权限账户。

• 不允许 Web 服务账户随意修改系统文件。

• 限制应用程序访问不必要的目录。

• 不使用拥有过高权限的数据库账户。

• 对敏感目录和配置文件实施严格访问控制。

• 限制服务器不必要的出站网络连接。

• 将生产环境与开发、测试环境隔离。

最小权限原则不能保证漏洞不会被利用，但能够降低漏洞利用成功后的影响范围。

7. 建立依赖和漏洞扫描机制

PHP 项目往往不仅依赖 PHP 本身，还依赖大量第三方组件。

建议结合项目情况使用：

• Composer 依赖审计。

• 操作系统软件包漏洞检查。

• 容器镜像扫描。

• 代码安全扫描。

• Web 应用安全测试。

• 服务器日志监控。

例如，可以在 Composer 项目中执行：

composer audit

该命令用于检查项目依赖中已知的安全问题，但它不能替代 PHP 运行时自身的版本检查。

如果 PHP 安全漏洞已经通过操作系统软件包、容器镜像或第三方产品引入，就必须同时检查这些供应链环节。

九、建议企业建立怎样的 PHP 安全响应流程？

对于企业网站和生产系统，建议把漏洞处理变成标准化流程，而不是每次等到安全事件发生后再临时应对。

可以参考下面的处理机制。

阶段	主要工作	目标
漏洞发现	关注 PHP 官方公告及安全机构通知	尽早获取风险信息
资产盘点	识别 PHP 版本、部署方式和相关组件	明确影响范围
风险评估	判断系统是否暴露在公网以及业务重要程度	确定修复优先级
变更准备	备份、兼容性测试、制定回滚方案	降低升级风险
漏洞修复	安装官方或供应商提供的安全补丁	消除已知漏洞
修复验证	检查版本、服务状态和业务功能	确认修复生效
安全复查	检查日志、异常进程和可疑文件	判断是否存在入侵迹象
持续改进	更新资产台账、补丁流程和监控规则	降低未来风险

对于严重的远程代码执行漏洞，不应机械地等待常规维护窗口。

如果系统暴露在公网且暂时无法修复，应根据风险评估考虑限制外部访问，必要时暂时隔离相关服务，直到能够安全修复。

十、未来 PHP 安全防护的三个趋势

除了处理当前漏洞，未来的 PHP 安全工作还会受到几个趋势的影响。

1. 从单纯的代码安全转向全链路安全

过去，很多团队把安全重点放在 SQL 注入、跨站脚本和文件上传等应用层问题上。

这些问题依然重要。

但运行时、操作系统、容器基础镜像、第三方扩展以及供应链中的漏洞，同样可能影响整个应用。

未来的安全管理需要同时覆盖代码、依赖、运行时和基础设施。

2. 从人工排查转向自动化资产管理

如果一个企业拥有几十个网站、多个测试环境和大量容器，仅靠人工逐台检查版本很容易遗漏。

通过自动化资产清单、依赖扫描和版本监控，可以更快发现受影响的系统。

但自动化扫描的结果仍然需要结合实际部署情况验证，尤其要关注命令行 PHP 与 Web 运行时不一致、多个版本并存以及容器未及时重建等情况。

3. 从漏洞修复转向持续风险管理

安全工作不能只在漏洞曝光后启动。

更成熟的团队会提前建立：

• 资产清单。

• 软件生命周期管理。

• 漏洞告警机制。

• 自动化测试。

• 补丁发布流程。

• 安全事件响应预案。

• 备份与恢复机制。

这样，即使未来再次出现严重的 PHP 漏洞，也能更快确认影响范围并完成处置。

十一、总结

2026 年 10 月 21 日发布的两个 PHP 高危安全漏洞，再次提醒我们：安全问题不仅存在于业务代码中，也可能隐藏在程序运行时的底层实现中。

对于 PHP 开发者、运维人员和企业管理者来说，当前最重要的工作包括：

1. 核对所有 PHP 运行环境的实际版本。

2. 对照 PHP 官方公告确认是否受到影响。

3. 优先升级到包含安全修复的受支持版本。

4. 在升级后检查服务状态和业务功能。

5. 排查异常日志、进程、文件及潜在入侵迹象。

6. 建立持续的版本管理、依赖扫描和漏洞响应机制。

真正可靠的安全防护，不是认为自己的代码没有问题，而是建立一套能够及时发现问题、快速修复漏洞、验证修复结果并持续改进的机制。

对于仍在使用旧版 PHP 的项目，尤其需要尽快制定升级计划。

一次及时的安全更新，可能避免后续更复杂的服务器恢复、数据泄露和业务中断问题。

安全不是一次性的工作，而是贯穿软件开发、部署和运行全过程的长期任务。

---

参考资料

1. PHP 官方安全公告

   PHP: News Archive - 2026

2. PHP 官方支持版本说明

   PHP: Supported Versions

3. PHP 官方下载页面

   PHP: Downloads

4. PHP Foundation：Today's PHP Security Release, and How We're Strengthening PHP Security

   Today's PHP Security Release, and How We're Strengthening PHP Security --- The PHP Foundation --- Supporting, Advancing, and Developing the PHP Language

5. CERT-EU：Critical Vulnerabilities in PHP

   CERT-EU - Critical Vulnerabilities in PHP

6. Canadian Centre for Cyber Security：Critical vulnerabilities impacting PHP

   AL26-026 - Critical vulnerabilities impacting PHP - CVE-2026-109618 and CVE-2026-109619 - Canadian Centre for Cyber Security

本文用于技术交流与安全防护参考。具体修复方案请以 PHP 官方公告、操作系统发行版安全公告和实际部署环境为准。