TencentOS 安全团队监测到 PHP 存在远程代码执行系列漏洞（CVE-2026-109618、CVE-2026-109619，代号 php2shell）。两个漏洞成因不同：CVE-2026-109618 源于 PHP 处理内存耗尽（OOM）错误时的异常退出机制存在缺陷，导致当前请求在内存未完全初始化的状态下被收尾流程处理；CVE-2026-109619 源于 PHP 常驻 worker 进程跨请求复用的全局状态未被正确重置，使后续请求访问到已释放的陈旧内存。攻击者均可通过构造特制 HTTP 请求（典型为 multipart 上传请求），在无需身份验证的情况下触发上述缺陷并实现远程代码执行。
该漏洞于 2026 年 10 月 21 日公开披露，影响 TencentOS Server 2.4、3.1、3.3、4 全系列产品的 PHP 软件包。监测到漏洞情报后，TencentOS 安全团队第一时间对漏洞进行分析和修复，对应修复版本已经过充分测试验证后发布。鉴于该漏洞影响范围较大，建议您根据 TencentOS 安全团队提供的修复方案进行修复，或应用临时缓解措施。
注意：若您已使用 TencentOS Server，建议您及时开展风险自查，如受影响，请及时根据 TencentOS Server 提供的方案进行防护，确保您的系统安全。
1. 漏洞详情
两个漏洞均位于 PHP 引擎的内存管理与请求生命周期核心代码，影响所有以常驻 worker 模式对外提供 Web 服务的 PHP 站点，与具体应用代码无关。按部署方式不同，两个漏洞的具体表现如下：
CVE-2026-109618（内存耗尽错误路径）：PHP 在请求处理过程中耗尽内存时会进入异常退出路径，此时请求内存尚未完全初始化即被收尾流程处理。攻击者发送特制 HTTP 请求（如构造特定格式的 multipart 上传）使 PHP 耗尽内存即可触发。在 Apache mod_php 等默认配置的 SAPI 上，官方已证实可被利用于无需身份验证的远程代码执行；PHP-FPM 模式经官方源码分析同样存在易感路径，但尚无完整利用演示，一般配置下更可能导致 PHP worker 进程异常退出并重启，造成服务中断或性能波动。
CVE-2026-109619（请求间全局状态残留）：PHP 为提升性能采用常驻 worker 模型处理请求，部分全局状态会指向请求私有内存，需要在请求结束后重置，涉及 session、错误处理、扩展状态等功能路径。当 worker 进程内的全局状态在请求结束后仍指向已释放的内存时，同一 worker 处理的后续请求即可触发该漏洞。在 Apache mod_php 等默认配置下，官方已证实可被利用实现远程代码执行；PHP-FPM 模式下的利用依赖应用层操作触发状态发布并叠加致命错误，官方已验证该路径（经由 session 上传进度生命周期）同样可实现远程代码执行，但利用条件高于 mod_php。
两个漏洞的利用均需要精确控制内存耗尽时机与堆布局，攻击复杂度较高；利用成功后，攻击者可在服务器上执行恶意代码，进而获取服务器控制权。
警告：目前这两个漏洞的漏洞细节、PoC 均已公开，需要您尽快进行处理，以免出现安全事件。
2. 受影响 TencentOS Server 版本
TencentOS Server 4（PHP 8.3.x< 8.3.36）
TencentOS Server 3.3（
php:8.2 < 8.2.35;php:7.4 < 7.4.33-8）TencentOS Server 3.1（
php:8.2 < 8.2.35;php:7.4 < 7.4.33-8）TencentOS Server 2.4（
php:8.2 < 5.4.16-48）说明：该漏洞仅在 PHP 以常驻 worker 模式对外提供 HTTP 服务（Apache mod_php、PHP-FPM、FrankenPHP、LSAPI 等 SAPI），且服务端口可被外部访问时，才存在被远程利用的实际风险；CLI 一次性执行模式不受影响。
自查方式
1. 确认 PHP 版本。
登录待查环境并执行以下命令：
rpm -qa | grep php # 未安装则不受影响php -v # 查看版本号dnf module list php --enabled # 查看当前启用的 module stream（TencentOS Server 3）
若 PHP 主版本为 5.4、7.2、7.3、7.4、8.0、8.2、8.3，且版本号低于对应修复版本（7.4.33-8、8.2.35、8.3.36），则处于受影响范围，需继续排查部署模式。TencentOS 官方软件源未提供 8.4、8.5 版本的 PHP，若您自行安装了这两个版本，请对照上游修复版本（8.4.27、8.5.12）判断。
2. 确认是否通过 Apache 加载了 mod_php 模块。
执行以下命令：
httpd -M | grep php
若有回显，则已加载 mod_php 模块。TencentOS 官方软件源不发布 mod_php 插件，若环境存在该模块，请自行确认其来源并评估影响。
3. 确认是否有 PHP 服务正在运行。
执行以下命令：
# 查 PHP-FPM 主进程和 worker 进程ps aux | grep -E 'php-fpm|php[0-9.]*-fpm' | grep -v grep
有相关进程则表示有 PHP 服务正在运行，可结合上一步的版本检查结果判断是否受影响。
注意：以上命令仅覆盖 php-fpm 进程的检测。若业务通过 Apache mod_php、FrankenPHP、LSAPI 等其他方式运行 PHP，本命令无法检出，请结合实际服务进程名自行排查，不可仅凭该命令结果判断“无 PHP 服务运行”。
3. 漏洞修复方案
TencentOS Server 已完成该漏洞修复，修复版本按 module stream 发布。TencentOS Server 3 默认启用
php:7.2 流，而该流以及 php:7.3、php:8.0 暂无修复版本，需要切换到含修复版本的流。各版本修复版本如下：系统版本 | 软件包 | 修复后版本 |
TencentOS Server 2.4 | php | php-5.4.16-48.tl2.1 |
TencentOS Server 3.1 | php:7.4 | php-7.4.33-8 |
| php:8.2 | php-8.2.35-1 |
TencentOS Server 3.3 | php:7.4 | php-7.4.33-8 |
| php:8.2 | php-8.2.35-1 |
TencentOS Server 4 | php | php-8.3.36-1.tl4 |
修复命令如下：
# TencentOS Server 2.4# 已使用 php:5.4 ，直接升级sudo yum update -y php# TencentOS Server 3.1/ TencentOS Server 3.3# 已使用 php:7.4 或 php:8.2 流的环境，直接升级sudo dnf update -y php# 使用 php:7.2（默认）/ 7.3 / 8.0 流的环境，需先切换到含修复版本的流sudo dnf module reset php -ysudo dnf module enable php:8.2 -ysudo dnf update -y php# TencentOS Server 4sudo dnf update -y php
警告：在
php:7.2、php:7.3、php:8.0 流之间切换（例如切换到 php:8.2）属于跨大版本升级，可能影响依赖旧版本 PHP 的业务，请完成兼容性评估后在业务变更窗口执行。说明：可通过
dnf module list php --enabled 查看当前启用的流，dnf module list php 查看全部可用流。以 TencentOS Server 3.3 实测为例，启用 php:8.2 后可升级至 php-8.2.35-1。完成升级后，执行以下命令确认当前安装的 PHP 已是修复版本：
rpm -q php
确认输出版本不低于对应 TencentOS Server 修复版本后，可视为安装已成功。
警告：若 PHP 处于运行状态，还需根据实际运行方式重启服务。重启 PHP 服务可能导致服务中断，请各业务执行前完成影响性评估。
4. 临时缓解措施
以下配置措施按两个漏洞分别给出，可叠加使用。请使用 root 用户（或具备 php.ini 与服务管理权限的用户）修改，修改后需重启全部 PHP worker 生效。
说明：升级到包含完整修复的 PHP 版本是唯一彻底的修复手段，缓解措施仅作为正式升级前的临时风险规避。
CVE-2026-109618（内存耗尽错误路径）
设置
memory_limit = -1，并尽量以应用无法覆盖的方式配置（如 FPM pool 或 Apache 配置中的 php_admin_value），确认无任何 pool、目录或应用级设置将其改回有限值。保持
post_max_size 处于保守取值，适当调低 max_input_nesting_level，限制输入变量数与上传文件数；若业务不使用 multipart 表单，可在 Nginx 或接入层直接拒绝 multipart 请求。使用容器或 cgroup 内存限制作为可用性边界，并配合 OOM 策略，确保只终止出问题的 worker 进程。不要使用
RLIMIT_AS 或 RLIMIT_DATA 作为替代方案，这两者可能导致内存分配失败，从而命中存在漏洞的代码路径。重启所有 PHP worker，确认全部进程以新配置运行。
警告：此措施只消除了“可被外部请求操控的 PHP 内存上限失败”这一触发方式，底层内存分配（如
mmap()）本身的失败仍可能触及该漏洞路径，不能视为完全阻断。CVE-2026-109619（请求间全局状态残留）
1. PHP 8.5 版本在 php.ini 中设置
fatal_error_backtraces = 0。2. 在 php.ini 中设置
session.upload_progress.enabled = 0。3. FPM 场景且性能允许时，可设置
pm.max_requests = 1，使每个 worker 处理一个请求即回收。4. 清理 php.ini 与各 pool 中过时或无效的 INI 指令，避免攻击者可预测触发的 fatal error 与告警路径，随后重启所有 PHP worker。
警告：
memory_limit = -1 取消了 PHP 进程级内存上限，异常业务可能导致进程内存持续增长，直至被系统 OOM killer 终止；pm.max_requests = 1 会显著增加进程回收开销、降低服务吞吐。请业务排查后执行。
