AI 发现 PHP 核心高危漏洞 PHP2Shell，影响全球七成网站

AI 发现 Web 核心架构中的关键漏洞

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 密钥和证书。
• 通过内存泄露窃取敏感数据，而无需先实现远程代码执行。这使得使用专注于恶意代码执行的工具更难检测到此类活动。

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

常见 PHP 软件

• WordPress
• Moodle
• Nextcloud
• Laravel
• Symfony
• Drupal
• Joomla
• MediaWiki

PHP2Shell 实战演示

观看 PHP2Shell 自动识别每个应用程序，并在受控测试环境中演示预认证命令执行的过程。

• 下载 WordPress 演示视频。WordPress 预认证 RCE 演示
• 下载 Drupal 演示视频。Drupal 预认证 RCE 演示
• 下载 Joomla 演示视频。Joomla 预认证 RCE 演示

漏洞详情

该研究在 PHP 核心中发现了两类相关漏洞：内存越界损坏（out-of-memory corruption）和跨请求的陈旧全局状态（stale global state across requests）。它们分别被追踪为 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 以更频繁地回收 worker。这可以减少跨请求的损坏状态持久化，但会带来性能开销，且无法解决不依赖多请求的机制。

限制利用的影响

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

升级后的加固

PHP 安全公告描述了修复中引入的新硬性内存限制。达到该限制会终止进程并阻止关闭处理程序运行。作为升级的一部分，请审查其对应用的运营影响。

打补丁后：

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

这些步骤支持安全更新后的应用弹性，但不能替代补丁修复。

技术细节

如需了解技术分析和协调披露详情，请阅读来自研究和响应团队的官方博客文章。

• Wiz Research：阅读官方文章
• OpenAI：阅读官方文章
• Calif：阅读官方文章
• PHP Foundation：阅读官方文章
• Akamai：阅读官方文章
• Imperva：阅读官方文章
• Cloudflare：阅读官方文章
• Corelight：阅读官方文章
• CrowdStrike：阅读官方文章
• Unit 42：阅读官方文章
• [

Cisco Talos：阅读官方文章](https://blog.talosintelligence.com/two-critical-rces-in-php-core/)

问答

研究确定的受影响版本可追溯至 PHP 5.4，在修复之前，几乎每个 PHP 版本都至少受到一个问题的影响。暴露风险取决于版本、配置以及具体的漏洞。请对照官方发布的受影响版本指南检查每一个 PHP 运行时环境，包括用于服务自定义应用的运行时环境。有关补救措施，请参阅升级 PHP。

不会。这些应用程序只是用于演示远程代码执行的代表性目标。存在漏洞的代码位于 PHP 本身中，可能会影响其他应用程序，包括运行在受影响 PHP 运行时上的简单“Hello World”应用。

所演示的远程代码执行和内存泄露攻击不需要身份验证或应用账户。不同变体的具体要求有所不同。

PHP 进程内存中可能包含属于其他请求或服务器本身的密码、身份验证令牌、API 密钥和证书。敏感数据可能在未实现远程代码执行的情况下被泄露。

对所有受影响的运行时环境应用 PHP 安全更新，并重启相关服务和 worker。该修复解决了根本的故障模式及其变体。仅更新应用程序或进行临时配置更改不能替代 PHP 更新。

行业合作伙伴已为无法立即更新的客户准备了指南、检测方案和临时缓解措施。覆盖范围取决于服务提供商和利用路径。请遵循您提供商的 PHP2Shell 指南，但不要将保护规则视为更新 PHP 的替代品。

单一检测规则不太可能覆盖所有利用路径。调查信号包括异常大或格式错误的 PHPSESSID 响应 Cookie、不寻常的多部分请求后出现内存限制错误或重复的 HTTP 500 响应，以及无解释的 PHP worker 崩溃或重启。

这些信号有助于指导调查，但本身并不能确立利用行为的发生。它们的缺失也不能证明系统未受影响。某些攻击可以在服务器上执行恶意代码之前泄露敏感内存，且由于漏洞路径运行在应用层之下，应用日志可能包含很少的上下文信息。

无论是否观察到可疑活动，都应应用 PHP 安全更新。

php2shell 是我们为用于演示 WordPress、Drupal 和 Joomla 上未经身份验证的远程代码执行的组合利用脚本所起的名称。PHP2Shell 也指对这些核心 PHP 漏洞的更广泛研究。

Wiz Research 在发现、利用开发和补丁验证过程中使用了 Wiz Atlas、Gemini 4 Argon 和 GPT-5.6-Sol。前沿模型帮助处理复杂的利用链并将其适配到不同的部署环境中。Gemini 4 对利用开发和补丁验证做出了特别重要的贡献。参见 The AI inflection point。

Wiz 如何提供帮助

Wiz 客户可参阅 Wiz 威胁情报中心关于 PHP2Shell 的公告，以获取无代理（agentless）和运行时漏洞检测、通过 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，获取有关暴露面管理和修复的指导。