PHP2Shell 披露 PHP 核心 CVSS 9.2 漏洞及修复版本

AI 揭示 Web 基础设施核心中的严重漏洞

PHP2Shell 是一组近期已在 PHP 核心中修复的严重漏洞，严重程度最高达 CVSS 9.2，可允许未经身份验证的攻击者执行代码或暴露敏感的进程内存。PHP 为约 70% 的网站提供支持，包括 WordPress、Drupal 以及 Wikipedia 的 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 版本上的简单“你好世界”应用。

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

WordPress、Drupal 和 Joomla 是用于演示未经身份验证的远程代码执行漏洞的代表性目标。利用这些漏洞并不需要使用上述任何一个应用。

~70% 的网站使用 PHP

PHP 为约 70% 的网站提供支持

PHP 是 WordPress、Drupal 和 MediaWiki 背后的编程语言，而 Wikipedia 正是运行在 MediaWiki 之上。其核心引擎中的漏洞可能影响这一生态系统中的网站。

攻击者能做什么

• 在无需身份验证的情况下于受影响的服务器上执行代码，从而可能控制服务器、访问敏感数据、横向移动或篡改网站内容。
• 读取敏感的 PHP 进程内存，包括属于其他请求或服务器本身的密码、身份验证令牌、API 密钥和证书。
• 无需先实现远程代码执行，即可通过内存信息披露窃取敏感数据。这可能使专注于恶意代码执行的工具更难发现此类活动。

我们使用测试当时各项目的最新容器镜像，演示了针对 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 工作进程。这是唯一的完整修复。更新应用程序并不会更新其底层的 PHP 运行时。

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

如果无法立即升级

升级 PHP 是唯一的完整修复措施。以下措施可以在准备升级期间减少针对特定攻击路径的暴露，但无法解决所有变体。

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

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

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

不要将 RLIMIT_AS 或 RLIMIT_DATA 用作替代内存上限。PHP 公告警告指出，这些设置可能会触发相同的易受攻击的失效路径。

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

降低攻击者可控的内存压力

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

这些设置仅限制特定的内存压力来源。其他由攻击者控制、导致内存耗尽的路径仍然存在。

禁用 PHP 错误显示

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

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

在支持的情况下设置 fatal_error_backtraces = 0，并重启受影响的工作进程。这可以解决已演示的致命错误回溯机制，但其他机制仍可能触发这一漏洞家族。

减少工作进程复用

调低 PHP-FPM pm.max_requests，以更频繁地回收工作进程。这可以减少损坏状态在不同请求之间持续存在的可能性，但会带来性能开销，也无法应对不依赖多个请求的机制。

限制漏洞利用的影响

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

升级后的加固

PHP 公告称，此次修复引入了一个新的硬性内存限制。达到该限制会终止进程，并使关闭处理程序无法运行。升级时，应审查其对应用程序运行的实际影响。

应用补丁后：

• 结合请求大小限制和预期的应用程序内存使用量，审查 memory_limit。重新审视升级前使用的任何临时 memory_limit = -1 设置，并遵循 PHP 的最终建议。
• 在支持合法上传的同时，将 post_max_size 合理地设定在配置的内存预算之下。
• 将 max_input_nesting_level 限制在应用程序所需的深度，并测试复杂表单。
• 考虑 expose_php = 0，以减少 PHP 版本信息披露。这是一项可选的加固措施，不能修复 PHP2Shell。

这些步骤有助于增强应用程序在安全更新后的韧性，但不能替代补丁修复。

问题与解答

研究发现，最早可追溯至 PHP 5.4 的版本均受到影响；在此次修复之前，几乎每个 PHP 版本都至少存在一个受影响的问题。暴露情况取决于版本、配置和具体漏洞。请对照官方的受影响版本指南检查每个 PHP 运行时，包括为自定义应用程序提供服务的运行时。有关修复措施，请参阅 升级 PHP。

Wiz 如何提供帮助

Wiz 客户可参阅 Wiz Threat Intel Center 关于 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

• Google 的 Gemini 团队

• OpenAI

• Calif

• Google Cloud

• AWS

• Microsoft

• Automattic

• Fastly

• Akamai

• Imperva

• Cloudflare

• Vercel

• Corelight

• CrowdStrike

• Unit 42

• Cisco Talos

提前防范 PHP2Shell

需要帮助识别受影响的 PHP 环境或规划后续步骤？请联系 Wiz，获取有关暴露情况和修复措施的指导。