PHP2Shell：PHP两个严重漏洞与应对措施

发生了什么，为什么应尽快处理

截至2026年10月22日，PHP已在21日发布针对CVE-2026-109618和CVE-2026-109619的安全更新，两者合称PHP2Shell。问题位于处理网页请求的PHP引擎，而不只是某个CMS插件。攻击可能使未认证者在脆弱服务器执行代码。应立即重视，但不能由此认定某个网站已经遭入侵。

官方涉及PHP-FPM、Apache mod_php、php-cgi、FrankenPHP及LiteSpeed。PHP认为mod_php风险最高，记录了应用代码运行前的已演示利用。网站小、没有登录表单或插件已更新，都不足以证明安全。应识别真正处理请求的PHP并确认修复。暴露情况取决于版本、供应商和配置，本文不判断具体服务器状态。

两个漏洞与修复版本

CVE-2026-109618与内存不足处理过程中的内存损坏有关。CVE-2026-109619涉及内部状态在关联内存释放后存留，并可能被同一工作进程的后续请求重用。PHP Foundation解释了两者和修复过程。区分原因有助于避免把事件简化成通用配置技巧。决定更新不需要重现攻击，本文不提供针对公共服务的利用测试或故意引发故障的命令。

10月21日修复版本为8.5.12、8.4.27、8.3.36及8.2.35。操作前查阅最新公告，后续可能有新修订。发行版可回补补丁而保留不同基础版本，Ubuntu在USN-8948-1列明包版本。不要只比较解释器字符串与网上列表，应核对包和供应商公告。PHP 8.1及更早版本已无项目官方支持，发行商修复并不恢复上游支持。

CVE-2026-109618 / CVE-2026-109619
PHP 8.2.35 | 8.3.36 | 8.4.27 | 8.5.12

向托管商询问什么，管理员验证什么

使用托管服务时，请求确认两个CVE对应的安装包、受影响服务及活动进程已使用修复。范围应包括各域名、进程池、容器和内嵌PHP产品，而不只终端。命令行版本不一定就是网站运行版本。自行管理时使用发行版或供应商说明的更新渠道，先保留恢复访问和适当备份，不下载未经验证消息或仓库中的所谓补丁。

安装后按供应商说明更新进程，并核对实际运行的版本或包。测试关键功能，记录修复时间。只升级CMS或清缓存不能代替运行时修复。若有入侵迹象，保留证据并启动事件响应：补丁不会撤销攻击者已经做出的修改。这是运行层面的完成检查，不是远程诊断。首页恢复仍需技术确认与功能验证。

无法立即更新时，以及WikiURL的边界

PHP明确只有更新才是完整解决办法。临时缓解仅减少特定攻击途径，不能让安装变安全。不要不了解影响就照抄内存或会话设置。ENISA建议优先处理暴露系统，不能及时修复时考虑与公共网络隔离。与管理员协调安全管理入口和中断通知。WAF规则或应用看似正常，都不代替补丁，也不保证全面防护。

WikiURL可以在维护后检查公开地址的HTTP响应和最终目标，但不能识别真实PHP或证明这两个CVE已修复。200与HTTPS锁标志不是漏洞评估。不要提交秘密或公开phpinfo作为凭证。分别保留供应商确认、活动进程验证和服务测试。应紧急更新并验证结果，既不凭空宣称入侵，也不因网页能打开就放心；本文不为任何具体安装提供已修复认证。