PHP2Shell：核心 PHP 中的高危漏洞家族及修复方案

AI 揭示了网络支柱中的关键漏洞

PHP2Shell 是近期在 PHP 核心中修复的一系列高危漏洞，严重程度达到 CVSS 9.2，可允许未经身份验证的攻击者执行代码或暴露敏感的进程内存。PHP 支撑着大约 70% 的网站，包括 WordPress、Drupal 和维基百科的 MediaWiki 等平台。

研究与负责任披露：Wiz Research — Sagi Tzadik、Shir Tamari、Nir Ohfeld 和 Tomer Schwartz；OpenAI Codex Security — Amy Burnett；Calif — Ryan A.

什么是 PHP2Shell？

PHP2Shell 是 PHP 核心中的一系列内存安全漏洞。它包含两个相关的漏洞类别，对应两个 CVE：由内存不足处理引发的破坏，以及跨请求残留的陈旧全局状态。

受影响的代码位于 PHP 本身。即使网站的应用代码是安全的，也可能会受到影响，包括在受影响的 PHP 版本上运行的简单“Hello World”应用程序。

运行最新打过补丁的 PHP 版本的网站受到了保护。PHP 团队以极高的速度和专业精神回应了这些报告，与研究人员紧密合作以提供全面的修复方案。

WordPress、Drupal 和 Joomla 是用于演示未经身份验证的远程代码执行的代表性目标。攻击并不一定需要这些应用程序之一。

~70% 的网站使用 PHP

PHP 支撑着大约 70% 的网站

PHP 是 WordPress、Drupal 以及运行维基百科的软件 MediaWiki 背后的编程语言。其核心引擎中的漏洞可能会影响整个生态系统中的网站。

攻击者可以做什么

• 在未经身份验证的情况下在受影响的服务器上执行代码，从而可能控制服务器、访问敏感数据、进行横向移动或篡改其网站。
• 读取敏感的 PHP 进程内存，包括属于其他请求或服务器本身的密码、身份验证令牌、API 密钥和证书。
• 在尚未实现远程代码 execution 之前，通过内存泄露窃取敏感数据。这会使得专注于恶意代码执行的工具更难以检测到该活动。

我们在测试时使用 WordPress、Drupal 和 Joomla 最新的容器镜像，演示了针对它们的远程代码执行。我们还演示了与应用程序无关的内存泄露。

PHP2Shell 实战

观看 PHP2Shell 在受控测试环境中自动识别各个应用程序并演示预身份验证命令执行。

• WordPress预身份验证 RCE 演示

• Drupal预身份验证 RCE 演示

• Joomla预身份验证 RCE 演示

漏洞详情

该研究在 PHP 核心中发现了两个相关的漏洞类别：内存不足破坏和跨请求的陈旧全局状态。它们的跟踪编号为 CVE-2026-109618 和 CVE-2026-109619，严重程度为 CVSS 9.2。

这些漏洞类别包含多个攻击路径，具有不同的利用要求和影响。PHP-FPM RCE 已通过应用级代码路径得到证实。PHP 团队的修复针对的是潜在的故障模式，而不仅仅是演示的路径。

升级 PHP

在每个运行时上安装修复后的 PHP 版本，然后重启 Apache、PHP-FPM 以及任何长时间运行的 PHP worker。这是唯一完整的修复方案。更新应用程序并不会更新其下方的 PHP 运行时。

官方 PHP 版本可从 php.net 获取。下游发行版将通过其正常的更新渠道提供相应的软件包更新。

如果您无法立即升级

升级 PHP 是唯一的完整修复方案。在您准备升级时，以下措施可能会降低对特定利用路径的暴露风险，但它们无法解决所有变体。

某些措施可能会影响应用程序的功能、性能或可用性。请根据应用程序的需求测试配置更改，并尽快应用 PHP 安全更新。

考虑禁用 PHP 的有限内存限制

设置 memory_limit = -1 可以阻止某些依赖于 PHP 内存限制处理的攻击路径，但它将内存耗尽的处理转移给了操作系统。通过此配置，内存耗尽的 worker 可能会被终止，从而中断请求并影响服务器的稳定性和可用性。如果您决定启用此功能，请使用 Linux cgroup v2 memory.max 或同等的操作系统机制，以帮助控制资源消耗并限制对 PHP 进程可用性的影响。通过管理方式应用配置更改并重启受影响的 worker。

请勿使用 RLIMIT_AS 或 RLIMIT_DATA 作为替代的内存限制。PHP 安全公告警告称，这些设置可能会触发相同的漏洞故障路径。

此措施不涵盖特定于应用程序的大内存分配路径或与内存无关的触发因素。在多线程部署中，终止进程也可能会中断在其他线程上运行的请求。

减少攻击者控制的内存压力

• 将 post_max_size 降低至与您的应用程序上传需求兼容的值。这也限制了文件上传，因此请测试合法的上传流程。
• 在应用程序允许的情况下降低 max_input_nesting_level。复杂的表单可能需要更高的限制。
• 如果应用程序不依赖于上传进度跟踪，请设置 session.upload_progress.enabled = 0。

这些设置限制了内存压力的特定来源。通往内存耗尽的其他攻击者控制路径依然存在。

禁用 PHP 错误显示

在生产环境中设置 display_errors = 0 并重启受影响的 worker，以防止 PHP 错误输出暴露给远程用户。这减少了一个额外的信息泄露路径，但并未修复底层漏洞。

在适用的情况下禁用致命错误回溯

在支持的地方设置 fatal_error_backtraces = 0 并重启受影响的 worker。这解决了已演示的致命回溯机制，但其他机制仍可能触发该漏洞系列。

减少 worker 复用

降低 PHP-FPM pm.max_requests 以更频繁地回收工作进程。这可以减少跨请求损坏状态的持续性，但会带来性能成本，且无法解决不依赖多请求的机制。

限制利用的影响

在与应用程序兼容的情况下，使用 SELinux 或 AppArmor 策略来限制工作进程的功能以及其他程序的执行。这些控制措施可以限制影响，但不应被视为能够阻止所有利用或内存泄露。

升级后加固

PHP 建议在修复方案中引入了新的硬内存限制。达到该限制会终止进程，并阻止关闭处理程序（shutdown handlers）运行。请将对应用程序的运营影响评估作为升级的一部分进行审查。

打补丁后：

• 结合请求大小限制和预期的应用程序内存使用情况审查 memory_limit。重新评估升级前使用的任何临时 memory_limit = -1 设置，并遵循最终的 PHP 建议。
• 在支持合法上传的同时，将 post_max_size 保持在配置的内存预算之下适当的水平。
• 将 max_input_nesting_level 限制在应用程序需要的深度，并测试复杂的表单。
• 考虑 expose_php = 0 以减少 PHP 版本泄露。这是可选的加固措施，无法修复 PHP2Shell。

这些步骤有助于提高应用在安全更新后的韧性。它们不能替代打补丁。

问题与解答

研究发现，受影响的版本可追溯至 PHP 5.4，在修复之前，几乎每个 PHP 版本都至少受一个问题影响。暴露情况取决于版本、配置和具体的漏洞。对照官方受影响版本指南检查每一个 PHP 运行时，包括为自定义应用提供服务的运行时。请参阅 Upgrade PHP 获取修复方案。

Wiz 如何提供帮助

Wiz 客户可以参考 Wiz Threat Intel Center advisory for PHP2Shell，获取无代理和运行时漏洞检测、通过 Wiz Defend 和 Sensor 进行的利用检测、自动响应策略、修复指导以及威胁狩猎指导。

协调与致谢

来自 Wiz Research、OpenAI Codex Security 和 Calif 的研究人员与 PHP 安全团队以及 Google 的 Gemini 团队合作，共同完成了发现、协调和补丁验证工作。

Google Cloud、Cloudflare、AWS、Microsoft、Automattic、Fastly、Akamai、Imperva、Vercel 以及其他行业合作伙伴协助为无法立即更新的组织准备了客户指导、检测方案和临时缓解措施。

研究与行业合作者：

• Wiz

• PHP

• Gemini team at Google

• OpenAI

• Calif

• Google Cloud

• AWS

• Microsoft

• Automattic

• Fastly

• Akamai

• Imperva

• Cloudflare

• Vercel

• Corelight

• CrowdStrike

• Unit 42

• Cisco Talos

走在 PHP2Shell 的前面

需要帮助识别受影响的 PHP 环境或规划下一步行动？联系 Wiz 获取关于暴露情况和修复的指导。