PHP2Shell是2026年10月21日披露的严重PHP漏洞的统称。如果你的网站使用PHP，首先要确认的是实际处理访问者请求的运行时是否已安装安全修复。更新插件，或看到防火墙控制台显示正常，都不能回答这个问题。

PHP2Shell影响网站底层的PHP运行时，可能让攻击者在未经身份验证的情况下远程执行代码。PHP已在8.2.35、8.3.36、8.4.27和8.5.12中发布修复，你需要确认实际处理Web请求的环境使用了修复版本，或有文档可核实的供应商回移补丁。请保持防御措施启用，但不要把WAF或临时配置变更当作补丁的替代品。

信息核查时间：2026年10月21日17:15 UTC。 本文反映修复已经发布的状态，而不是最初仍在等待版本发布的公告。供应商软件包和响应指导可能快速变化，因此在实施变更前，请重新查看文中的安全公告。

PHP2Shell究竟确认了哪些事实？

PHP安全团队确认了两项可能无需登录即可触发远程执行的缺陷。官方公告 指出，处理Web请求的PHP安装环境存在风险，并特别强调Apache搭配mod_php是风险最高的配置。能否被利用取决于运行时、构建方式和请求处理环境。

漏洞编号PHP的说明实际需要关注的问题
CVE-2026-109618请求清理过程中发生内存不足损坏PHP处理内存分配失败时，可能使用无效的请求状态
CVE-2026-109619请求所属的过期全局状态同一工作进程的后续请求可能访问已释放内存的引用

两份公告的CVSS v4.0评分均为9.2。请阅读CVE-2026-109618 和CVE-2026-109619 的一手报告，不要只依赖社交帖子推荐的临时缓解方法。

这意味着应当迅速采取行动，但并不证明所有PHP网站都已被入侵。严重漏洞、攻击尝试和已确认的入侵是不同的调查结论。你的响应工作应当弄清自身系统实际属于哪种情况。

哪些PHP版本修复了PHP2Shell？

下表列出了今天发布的受支持分支安全版本。这是核对上游安装版本的起点。发行版的软件包可能通过不同的软件包修订号携带这些修复。

PHP分支同时修复两个漏洞的安全版本
PHP 8.28.2.35
PHP 8.38.3.36
PHP 8.48.4.27
PHP 8.58.5.12

这些版本已在PHP发布公告 中得到确认。如果发行版或托管供应商使用回移修复，请索取其安全通知和已安装软件包的确切修订号。仅靠版本字符串，可能把已修补的供应商软件包误判为未修补，也可能漏掉过时的捆绑运行时。

PHP 8.1及更早版本已不再获得常规上游更新。PHP也为7.4、8.0和8.1提供了最小范围的源码回移补丁，但这不意味着持续支持已经恢复。应明确由谁负责供应商支持的修复，或制定升级计划。PHP支持状态表 说明了各分支当前的支持情况。

请单独检查容器、嵌入式PHP安装和一体化设备。NCSC-NL运维指导 明确提醒，更新宿主机PHP不一定会更新这些运行时。

WordPress、Laravel等PHP网站也受影响吗？

首先检查执行应用程序的解释器。WordPress网站、Laravel应用和自建PHP门户即使应用代码完全不同，也可能使用同样过时的运行时。安装最新主题、插件或框架版本，并不会安装PHP运行时的安全修复。

如果使用托管服务，请询问每个网站实际使用哪个PHP版本或已修补软件包、变更是否覆盖了所有节点，以及是否完成了必要的工作进程重启。应向托管平台索取证据，不要把应用更新通知视为确认依据。

对于自行管理的系统，资产清单应覆盖附属网站、管理界面、旧虚拟主机和预览环境。生产应用可能已更新，但同一基础设施上的旧网站仍然可以从公网访问。请为每个暴露环境记录负责人和修复决定。

不要因为上传表单没有被使用，就认定部署环境安全。PHP公告描述的是运行时的请求处理路径。访问者看到的应用功能并不构成完整的暴露面评估。

如何修补并验证真正服务访问者的运行时

确认实际运行的环境

识别Web服务器的集成方式、运行时软件包或容器镜像、配置来源和服务负责人。将这份清单关联到客户实际使用的主机名。工程师如果检查了错误主机，就可能给出看似可信、实际上与目标无关的版本报告。

以下只读命令用于识别命令行安装环境及其配置：

1php -v
2php --ini

它们不能证明PHP-FPM、Apache或其他Web服务集成实际运行的版本。请通过已认证的托管信息或受控的管理员检查确认真正提供服务的运行时。不要留下向公众暴露配置和环境详情的诊断页面。

对于容器部署，应验证真正接收流量的镜像和应用实例，而不只是镜像仓库中的替代镜像。变更记录要包括负载均衡器后的所有实例，以及单独运行的工作进程服务。

应用受支持的修复并测试应用

使用持续维护的软件包来源或镜像供应商提供的正式更新流程。记录已安装修订号，以及覆盖两个CVE的供应商公告。应根据部署方式计划服务重启或实例替换，不要假设下载软件包就会改变正在运行的进程。

在可能中断服务的变更前保留相关日志。准备经过验证的备份和恢复方案，然后在更新后测试具有代表性的应用流程。如果应用使用这些功能，登录、会话、结账、上传和后台处理都是值得测试的候选项。

最后再次核对实际提供服务的运行时，完成变更验证。保留哪些实例已更新、流量何时切换、谁批准应用检查结果等证据。部署任务显示成功是有用的依据，但不等于完成了全部验证。

Cloudflare WAF能防护PHP2Shell吗？

Cloudflare报告已部署PHP2Shell WAF防护 ，并观测到攻击流量，相关防护面向Free和付费WAF客户。其公告描述了综合请求和响应信息的防护方式，同时明确建议客户即使有这些防护，也仍应修补PHP。

对于具体网站，应确认相关流量确实通过受保护服务，并且适用规则已启用。检查例外、绕过规则和可以通过其他路径访问的源站。这些是部署检查，不意味着Cloudflare的公告保证应用的每一条可能访问路径都受到保护。

将WAF事件数据作为调查材料保留。某个请求被拦截，可以证明规则匹配了该请求。但这不能证明源站没有通过其他路径被访问，也不能证明此前没有发生入侵。

在完成运行时更新期间，继续把WAF作为额外的防御层使用。不要仅仅因为控制台记录了被拦截的尝试，就推迟PHP修复。

临时缓解措施不能完整修复PHP2Shell

如果暂时无法打补丁，请与负责该系统的工程师或供应商一起遵循最新PHP公告。过期状态漏洞公告 解释了为什么必须在请求解析前禁用session.upload_progress.enabled，并且需要重启工作进程。公告特别提醒，不要为此依赖ini_set()或FPM的.user.ini。

这项变更只能阻断已经确认的会话相关路径，并不能覆盖所有变体。PHP 8.5还有涉及fatal_error_backtraces的单独指导。从论坛复制一小段配置，不能证明两个漏洞都已经得到处理。

内存不足漏洞公告 描述了不同的控制措施，包括请求限制和内存限制处理方式的变更。这些措施会影响资源和可用性。请针对实际部署审阅完整指引，不要随意取消生产服务器的内存边界。

如果打补丁前无法把暴露风险降低到可接受水平，应讨论限制受影响应用的公网访问。记录临时措施、限制条件、负责人和永久修复计划。临时缓解措施应有撤销或复查条件，不应变成没有文档记录的永久设置。

检查暴露情况后应该监控什么？

先建立基线，并保留重要时间段的记录。将Web请求与PHP、Web服务器和主机事件关联分析，不要把单个异常请求当作完整诊断。缺少日志的地方，应明确记录这一限制。

观测情况调查时需要回答的问题
意外的PHP工作进程退出或内存故障应用行为是否变化，相关时段处理了哪些请求？
新增或修改的可执行文件是否对应获批部署，还是无法解释的写入？
意外的子进程或出站连接Web工作进程是否有正当理由执行该活动？
WAF匹配事件与源站访问记录哪些请求被拦截，哪些路径到达了源站？
账户、计划任务或机密信息的变更能否把每项变更关联到获授权的操作人员？

这些是调查方向，不是PHP2Shell专属指标，也不是系统已被入侵的证据。正常运维也可能产生类似现象。同样，没有告警并不能证明未修补系统此前是安全的。

如果证据表明可能发生入侵，请保存证据，并在修补的同时安排事件处置。更新解释器不会清除持久化机制、撤销被盗凭证，也不会证明哪些数据曾被访问。应在响应计划中将它们分别处理。

常见问题

PHP2Shell漏洞利用是什么？ PHP2Shell指编号为CVE-2026-109618和CVE-2026-109619的PHP漏洞。它们涉及运行时的内存处理，可能允许未经身份验证的远程代码执行，并不只是WordPress插件缺陷。

检查PHP2Shell补丁时应核对哪些版本？ 2026年10月21日发布的受支持分支修复版本为PHP 8.2.35、8.3.36、8.4.27和8.5.12。如果使用发行版回移修复，应取得供应商公告，核对实际提供服务的环境中安装的准确修复软件包修订号。

更新WordPress能修复PHP2Shell吗？ 仅更新WordPress不会更新它底层的PHP解释器。应用维护仍应保持最新，但还需单独与托管供应商或服务器工程师核实PHP运行时的安全修复。

使用Cloudflare的网站会自动安全吗？ Cloudflare报告了WAF防护，但你的流量路径、适用规则和源站暴露情况仍需检查。请保持防护启用并修补PHP。防火墙控制台不能证明运行时已修复，也不能证明此前未发生入侵。

禁用会话上传进度功能就足够了吗？ 不够。PHP说明，这项措施阻断的是已确认的会话相关路径，不是所有变体。必须在适当配置层应用，并重启工作进程。仍然需要更新到修复运行时或经过验证的供应商回移补丁。

可以在生产网站上测试公开的漏洞利用代码吗？ 初步检查应优先采用版本、软件包和配置证据。如果验证确实需要利用测试，应取得明确授权，并在具备隔离、监控和恢复方案的受控环境中安排。不要对生产环境运行未经审查的利用脚本。

安装补丁能证明服务器此前没有被入侵吗？ 不能。补丁解决的是运行时缺陷，而事件评估要调查此前活动、持久化机制、凭证和可能的数据访问。应让这些工作相互衔接，并记录现有证据的局限。

需要PHP网站检查、监控或补丁支持？

我们可以帮助识别真正服务网站的PHP运行时、评估暴露情况、审查可获得的日志与防御措施，并规划所需补丁或受支持版本升级。如果环境需要持续观察，我们可以围绕已识别风险，商定监控范围、告警责任和升级处理流程。

我们的应用安全服务 支持评估和调查，服务器安全服务 则覆盖托管和配置边界。我们可以与你的托管供应商配合，验证供应商修复、协调变更，并记录更新后的应用检查结果。

有价值的结果是一份清晰记录，说明检查了什么、修补了什么、哪些问题仍不确定，以及谁负责后续工作。我们不会凭一个版本字符串或一次扫描就承诺系统完全正常。工作范围和可提供服务的时间应在开始前约定。

联系我们，咨询PHP2Shell暴露检查、安全监控或补丁支持 。请说明托管方式、受影响域名、已知PHP版本，以及有权批准变更的负责人。首次咨询请不要发送密码或访问令牌。