PHP2Shell严重漏洞曝光！艾体宝Mend.io快速排查与修复运行环境风险

PHP 底层运行环境出现漏洞，即使应用代码本身没有问题，企业系统也可能面临远程代码执行风险。

2026 年 10 月 21 日，PHP 官方发布安全更新，修复了两个严重的远程代码执行（RCE）漏洞：CVE-2026-109618 和 CVE-2026-109619。两个漏洞合称为 PHP2Shell，CVSS v4.0 评分均达到 9.2。

这意味着，风险不仅存在于存在缺陷的应用代码中，也可能隐藏在服务器、容器镜像及其他基础运行环境里。

面对这类严重漏洞，企业首先需要解决的问题是：哪些系统正在使用受影响的 PHP 版本？如何快速定位风险资产，并推动修复真正落地？

借助 Mend.io 的容器安全扫描、软件成分分析（SCA）与自动化依赖更新能力，企业可以更高效地完成漏洞排查与修复。

一、PHP2Shell：应用代码安全，不代表运行环境安全

PHP2Shell 涉及两个高危漏洞：

• CVE-2026-109618：与内存耗尽情况下的内存破坏有关，可导致远程代码执行。
• CVE-2026-109619：与过期的全局状态有关，同样可能导致远程代码执行。

根据 PHP 官方安全公告及 Mend.io 的技术分析，攻击者可能在未经身份验证的情况下触发漏洞，以 Web 工作进程的权限执行代码，并可能造成进程内存信息泄露。

此次漏洞影响 PHP 运行时本身，而非特定 PHP 应用的业务代码。因此，即使企业使用的 WordPress、Laravel 等应用没有发现代码缺陷，只要底层 PHP 运行环境处于受影响版本，仍然可能面临风险。

哪些环境需要重点排查？

• PHP-FPM、Apache mod_php、php-cgi 等 PHP 服务运行环境；
• 使用受影响 PHP 版本的服务器及虚拟机；
• 包含 PHP 运行时的 Docker 容器镜像；
• 由第三方供应商提供、内部难以直接检查底层组件的应用或设备。

PHP 官方此次修复涉及的主要上游版本包括 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。使用 Linux 发行版维护的软件包时，还需要核实发行版的安全公告与补丁记录，不能仅凭版本字符串判断是否已修复。

二、为什么高危漏洞发现容易，全面排查却不容易？

漏洞公布之后，企业真正面临的挑战往往不是能否找到漏洞编号，而是能否快速回答三个问题。

1. 资产在哪里？

PHP 可能直接安装在服务器中，也可能被封装在容器基础镜像、定制镜像或第三方应用中。开发团队熟悉应用依赖，但不一定掌握所有运行环境的具体版本。

如果缺少统一的组件清单，安全团队就需要逐一排查服务器、镜像和项目，容易遗漏非核心业务系统及内部管理工具。

2. 哪些资产确实受到影响？

仅仅发现系统使用 PHP，并不足以判断其是否存在漏洞。企业还需要核对组件版本、漏洞影响范围以及供应商是否已提供修复补丁。

对于采用 Linux 发行版补丁的环境，还需要结合具体软件包的安全更新记录进行判断。

3. 如何确保修复真正完成？

发现漏洞只是第一步。企业还需要协调开发、运维与安全团队，更新 PHP 运行时、重新构建镜像、部署修复版本，并确认相关服务已经重新启动。

如果漏洞信息停留在扫描报告中，没有进入实际修复流程，风险依然存在。

因此，企业需要的不只是漏洞检测工具，还需要贯通资产识别、风险定位与修复执行的安全管理流程。

三、Mend.io 如何助力 PHP2Shell 漏洞发现与修复？

针对 PHP2Shell 这类运行环境漏洞，Mend.io 可以通过容器安全扫描、软件成分分析和自动化依赖更新能力，帮助企业定位受影响资产并推进修复。

01 容器安全扫描：定位隐藏在镜像中的 PHP 风险

容器镜像是运行环境漏洞容易被忽视的地方之一。

例如，一个应用使用的 Dockerfile 可能引用了包含旧版 PHP 的基础镜像。即使应用自身的代码和依赖没有明显问题，底层运行环境仍可能存在高危漏洞。

Mend.io 的容器安全扫描能够检查镜像中的操作系统软件包等组件，并识别相关已知漏洞，帮助企业定位包含受影响 PHP 软件包的镜像。

借助这一能力，安全团队可以：

• 扫描容器镜像仓库及交付流水线中的镜像；
• 识别镜像中存在的受影响 PHP 软件包；
• 汇总存在风险的镜像，缩小排查范围；
• 为后续基础镜像更新和重新构建提供依据。

这使企业无需完全依赖人工逐个检查 Dockerfile，就能更系统地排查容器中的 PHP 运行环境风险。

02 软件成分分析（SCA）：识别项目中的已知漏洞

对于项目中使用的开源组件，Mend SCA 可以识别组件及其已知漏洞，并提供相应的风险信息和修复建议。

当 PHP 被识别为扫描范围内的组件时，Mend.io 可以针对相关漏洞生成安全发现，帮助团队将 PHP2Shell 与其他开源组件风险统一纳入管理流程。

安全人员可以据此进一步核查：

• 哪些项目或组件存在相关漏洞；
• 漏洞对应的组件版本及严重程度；
• 是否存在可用的修复版本；
• 应当优先处理哪些风险发现。

需要强调的是，PHP2Shell 属于 PHP 运行时漏洞，SCA 的有效发现范围取决于 PHP 组件是否被纳入扫描并被正确识别。对于未纳入项目依赖清单的服务器运行时，应结合容器扫描、主机资产盘点及软件包安全公告进行补充排查。

03 自动化依赖更新：推动修复进入实际开发流程

识别风险之后，企业还需要把修复动作落实到代码仓库和镜像构建流程中。

Mend Renovate 可以帮助团队自动化管理依赖更新。当受影响的 Docker 基础镜像发布了修复版本时，Renovate 可以针对相应的基础镜像标签创建更新 Pull Request（PR），由开发团队审核并合并。

这一流程能够帮助企业：

• 及时发现可用的基础镜像更新；
• 减少人工检查和维护版本的工作量；
• 将更新变更提交至现有代码评审流程；
• 推动受影响镜像使用修复后的基础镜像重新构建。

需要注意，创建更新 PR 并不等于漏洞已经修复。企业仍需完成变更审核、镜像重新构建、部署验证及必要的服务重启，才能确认修复真正落地。

四、从漏洞发现到修复验证，建立持续安全管理机制

PHP2Shell 再次提醒企业：软件安全不仅取决于应用代码，也取决于其依赖的组件和运行环境。

面对高危漏洞，企业可以建立以下处理流程：

第一步：全面盘点。 识别服务器、虚拟机、容器镜像及第三方托管环境中的 PHP 运行时，避免遗漏非核心系统。

第二步：识别风险。 通过 Mend.io 容器扫描和 SCA 等能力定位受影响组件，并结合 PHP 官方公告、Linux 发行版安全公告及实际部署信息确认影响范围。

第三步：执行修复。 优先升级至对应的修复版本或已包含安全补丁的软件包。对于容器环境，应使用修复后的基础镜像重新构建，而不是仅修改正在运行的容器。

第四步：验证结果。 重新扫描相关资产，确认漏洞状态；重启 Apache、PHP-FPM 等相关服务，并根据实际风险检查历史日志，排查潜在的异常活动。

第五步：持续监控。 将漏洞扫描与依赖更新纳入日常开发和交付流程，减少新版本发布后再次引入已知风险的可能性。

写在最后

高危漏洞的应对速度，取决于企业能否及时掌握软件资产、准确识别受影响组件，并将修复措施落实到实际运行环境中。

Mend.io 通过容器安全扫描、软件成分分析与自动化依赖更新，帮助企业将分散的组件风险纳入统一管理流程，提升漏洞排查与修复效率。

从 PHP2Shell 这样的运行时漏洞，到日常开源依赖风险管理，企业需要建立的不是一次性的漏洞响应机制，而是贯穿软件开发、构建与交付全过程的持续安全能力。

艾体宝 Mend.io，助力企业提升开源软件供应链安全管理能力，让漏洞发现更及时，让风险修复更可追踪。