CVE-2026-109618CVSS 9.2
内存耗尽导致的损坏
CVE-2026-109618 涉及内存不足时 PHP 的提前退出机制。未完整初始化的请求内存仍可被引用，随后在清理阶段被使用。补丁以新的软硬内存处理机制替代不安全的退出模式。mod_php 已验证完整未认证 RCE。官方认为 FPM 存在应用相关风险，但没有宣称此 CVE 已有完整 FPM 利用演示。
阅读指南 ↗独立 PHP 安全工具集
检查你的 PHP。让修复有据可依。
从实际版本出发，了解 PHP2Shell 补丁状态、判断结果的边界，并找到适合你部署环境的修复步骤。
保护隐私：输入内容仅在当前浏览器内处理。
PHP 是世界上最好的语言
9.2/10严重程度CVSS v4.0
02相关漏洞CVE-2026-109618 / 109619
04已修复分支PHP 8.2 → 8.5
18支持语言EN / 中文 / 日本語 / …
01 / 检查版本风险
一个版本，或整批服务器。
粘贴 PHP 版本、php -v 输出或每行一个版本。工具进行版本比对，不执行漏洞利用。
版本评估结果
下载 JSON ↓PHP2SHELL / FRAMEWORK / CMS
框架与 CMS 的 PHP2Shell 修复指南
按框架、博客或商城找到 PHP2Shell 修复路径：确认实际 PHP、核对应用兼容性、解决升级障碍，最后验证 CVE-2026-109618 与 CVE-2026-109619 均已修复。
PHP2SHELL / PHP2Shell 工具箱
研究解读与实用攻略
检测公开网站、检查本地配置和日志，或查找开源应急工具。每种结果都会说明依据和局限。
>_
PHP2Shell 工具箱
检测公开网站、检查本地配置和日志，或查找开源应急工具。每种结果都会说明依据和局限。
01用通俗的话理解 PHP2Shell
PHP 是网站的运行引擎，WordPress、Laravel 和插件运行在它上面。更新插件不等于更新 PHP。这两个运行时内存安全漏洞可能让异常请求清理演变成信息泄露或代码执行。公开网站检测只能寻找线索，实际 Web 运行时和补丁必须由主机商或管理员确认。
02是攻击尝试，还是已经入侵？
异常 multipart 请求或 WAF 告警可能是攻击尝试。内存耗尽、SIGSEGV/SIGABRT、HTTP 500 突增也可能由正常故障造成。PHP 异常子进程、外连、文件修改或未授权账号值得立即排查，但归因仍需证据。纯内存泄露可能不生成 Webshell 或新文件，文件扫描干净也不能排除。
03先保全证据，再改动主机
记录发现时间、域名、实例、运行时、异常表现及最近一次可信状态。导出原始访问、错误、WAF 和进程日志并保留时区；有条件时保全云审计记录和经授权的磁盘、内存快照。限制副本访问权限，记录哈希。不要把 Cookie、令牌和用户数据传给公开扫描站。取证前避免清空日志或直接删除可疑文件。
04如何阅读 Wiz 与 Calif 的技术研究
两份研究解释了请求生命周期的错误为何可能影响后续请求。CVE-2026-109618 官方公告验证了 mod_php RCE；FPM 的易受影响判断基于源码分析，并没有展示该 CVE 的完整 FPM 利用。CVE-2026-109619 则确认了依赖应用条件的 FPM 上传进度利用路径。判断每个 SAPI 的证据范围应看对应 GHSA，不要把所有部署说成同样已验证。
05Cloudflare：为什么要看响应
Cloudflare 介绍结合请求与源站响应的完整事务检测，可在匹配到可疑响应时阻断可能的数据流出，这对不启动 Shell 的泄露路径也有意义。文章中的上线时间只是历史记录，不代表你的账号和路由已覆盖。请核实规则可用性、排除项和事件日志；直接访问源站和未经过代理的主机，仍需要修复与排查。
02 / 补丁基线
四个分支，明确的升级目标。
PHP 安全团队于 2026 年 10 月 21 日公布。请在同一版本分支内比较。
PHP.net ↗
| PHP 分支 | 低于此版本的上游发行版 | 首个修复版本 | 安全支持结束 |
|---|---|---|---|
| PHP 8.5 | < 8.5.12 | ✓ 8.5.12 | 2029年12月31日 |
| PHP 8.4 | < 8.4.27 | ✓ 8.4.27 | 2028年12月31日 |
| PHP 8.3 | < 8.3.36 | ✓ 8.3.36 | 2027年12月31日 |
| PHP 8.2 | < 8.2.35 | ✓ 8.2.35 | 2026年12月31日 |
仍在使用 PHP 8.1 或更早版本？
这些分支不会获得 PHP 项目常规版本更新。7.4、8.0、8.1 有最小源码回移植；厂商补丁状态需单独核实。 阅读指南 ↗
03 / 从检测到修复
按步骤完成修复，回到工作。
01
识别资产
找到每套 PHP 运行时、软件包来源和站点处理器。
02
安装更新
使用含补丁的新构建或有据可查的厂商回移植包。
03
重启与验证
替换运行中的进程，验证所有实例。
Ubuntu 与 Debian
确认 php*-common 和实际 Web 处理器的软件包，分别查看 Ubuntu 或 Debian 对两个 CVE 的记录。下方命令以 PHP 8.3 举例，应替换成实际分支。确认已启用仓库提供修复包后再升级。changelog 缺失或未提及 CVE 时，应查厂商公告，不能把没有记录当作安全。
阅读指南RHEL、Rocky、AlmaLinux 等系统
确认 PHP 来自系统仓库、应用流还是第三方源，查询 RPM 完整修订和厂商安全勘误。保持软件包在同一兼容流。示例针对未加版本前缀的 php-* 包；并行安装及面板管理的包名不同。第三方源须提供同时包含两个修复的依据。
阅读指南Docker 与容器镜像
重启原有容器不会安装 PHP 补丁。需拉取已修复基础镜像、重建应用镜像，并替换所有运行容器。生产环境固定经验证的镜像摘要，滚动更新后逐副本检查。自建及厂商镜像需单独提供补丁依据。示例使用 PHP 8.4.27 FPM，Compose 服务占位符须换成真实名称。
阅读指南宝塔与 1Panel
面板 PHP 可以完全独立于系统 PHP。列出所有版本并映射各站点运行时，从可信面板更新渠道获取含两个 CVE 修复的包或镜像。面板更新不等于 PHP 更新。重启每个受影响服务或重建容器，切换站点处理器后逐站验证。不同面板版本的菜单名称可能不同。
阅读指南WordPress、虚拟主机与托管服务
更新 WordPress、Drupal 或 Joomla 不会更新 PHP。向主机商索取实际处理器、完整包修订、两个 CVE 的修复说明和进程重启凭据。面板中的同一分支可能对应不同构建。托管云服务或一体化设备应按产品厂商公告更新，不要自行替换捆绑运行时。
阅读指南PHP2SHELL / CVE
两个运行时漏洞，一次紧急更新。
PHP2Shell 是 PHP 自身的内存安全漏洞。即便应用程序已更新，底层解释器仍可能没有打补丁。
CVE-2026-109619CVSS 9.2
跨请求的残留状态
CVE-2026-109619 中，持久工作进程在请求内存释放后仍保留引用。下一个到达同一进程的请求可在正常初始化前使用残留值。确认路径包括 PHP 8.5 的致命错误回溯、会话上传进度生命周期。mod_php 和具备合适应用路径的 PHP-FPM 均验证了 RCE。
阅读指南 ↗PHP-FPM 可以豁免吗？
不可以。两个漏洞在不同 SAPI 中的利用条件不同。FPM 在请求启动失败时终止子进程，可阻止部分启动阶段的序列，但不消除应用执行阶段及跨请求路径。既不要认为所有架构都与 mod_php 演示完全一致，也不能据此省略 FPM 补丁。
发行版版本号与补丁回移植
Ubuntu、Debian 和企业 Linux 常保留旧的上游版本号，通过软件包修订加入安全补丁。仅看到 8.3.6，既不能证明受影响，也不能证明已修复。须同时匹配系统版本、软件源、架构、已安装修订和两个 CVE 的厂商状态。本工具不编造包修复门槛。
PHP 8.1 及更早版本
这些分支没有常规 PHP 官方更新。本次例外提供 7.4、8.0、8.1 的最小源码回移植，构建及验证由运营者负责。发行版或 LTS 厂商可能提供维护包。研究报告涉及最早 PHP 5.4，不同路径条件不同。应迁移到受支持分支，并核实过渡期间的厂商补丁。
临时缓解无法完整修复
只有完整补丁覆盖所有已知变体。配置可在升级前降低特定路径的暴露，但可能影响上传、性能和可用性。必须在解析请求前由管理员强制应用，并重启全部进程。同时阅读两个 PHP 公告。CDN 或 WAF 只能辅助降低风险，不能证明解释器已修复。
PHP2SHELL CHECKER
检测我的版本下一步：让运行时真正完成修复。
从版本开始，依据证据操作，验证实际为网站服务的 PHP 进程。