PHP2Shell 是什么？PHP 网站漏洞排查与修复指南
发布于
如果你的企业官网、WordPress 网站或电商系统运行在 PHP 上，近期需要优先处理一项运行环境安全更新：PHP2Shell。网站能正常打开、后台密码足够复杂，都不能证明服务器已经安全。
本文面向网站负责人和运维人员，按“确认环境 → 安装补丁 → 重启进程 → 验证业务”的顺序介绍处理方法。信息核对截至 2026 年 10 月 22 日；后续修复状态以 PHP 项目和系统供应商公告为准。
一、PHP2Shell 是什么？
PHP2Shell 是两项 PHP 核心漏洞的通称：CVE-2026-109618 和 CVE-2026-109619，两者的 CVSS v4.0 评分均为 9.2（严重）。在受影响环境中，攻击者可能无需登录，通过 HTTP 请求以 Web 工作进程的权限执行代码。这不等同于自动获得 root 权限，但已经可能影响网站文件和应用可访问的数据。PHP 官方安全公告
两项漏洞都与 PHP 请求生命周期中的异常状态有关：
- CVE-2026-109618：内存耗尽时的状态损坏。 内部请求数据尚未完成初始化，内存分配失败就中断了正常流程；随后的清理阶段可能使用无效数据。官方技术说明
- CVE-2026-109619：遗留的全局状态。 请求使用的内存释放后，部分内部状态仍被保留；同一工作进程处理后续请求时，可能访问已经失效的状态。官方技术说明
这类问题发生在 PHP 运行时，单独更新主题、插件或业务代码，不能替代 PHP 补丁。
二、哪些网站需要排查？
PHP 官方要求所有处理 Web 请求的 PHP 安装检查更新，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP 和 LiteSpeed。不同运行方式的攻击条件与已验证程度不同，不能据此把 PHP-FPM 判断为安全。官方特别指出，mod_php 已有在应用代码执行前触发攻击的验证结果。PHP 官方公告
因此，使用 WordPress、Laravel、Drupal 或其他 PHP 系统的网站，都应核对底层环境。即使主站采用其他语言，也要检查同一基础设施上的旧站、后台、测试站和独立 PHP 工具。
没有发现异常不代表没有漏洞；存在漏洞也不等于已经被入侵。 是否遭到攻击，需要结合日志与主机证据判断。
三、应该升级到哪个版本？
PHP 于 2026 年 10 月 21 日发布以下修复版本。使用上游版本时，应更新到所在分支的下列版本或包含修复的更新版本：PHP 发布公告
| PHP 分支 | 首个修复版本 |
|---|---|
| PHP 8.2 | 8.2.35 |
| PHP 8.3 | 8.3.36 |
| PHP 8.4 | 8.4.27 |
| PHP 8.5 | 8.5.12 |
发行版软件包不能只看上游版本号。 Ubuntu 等供应商可能将补丁回移到较旧版本，判断依据应是系统版本、完整软件包版本和供应商安全公告。例如 Ubuntu 24.04 的修复包为 8.3.6-0ubuntu0.24.04.13，虽然不是上游的 8.3.36，也已经包含修复。Ubuntu 官方修复说明
PHP 8.1 及更旧分支已不再获得 PHP 项目的常规更新。部分发行版或长期支持服务提供回移补丁；PHP 项目也为 7.4、8.0、8.1 提供了最小源码补丁。这并不意味着这些分支恢复支持。应优先迁移到受支持分支，暂时无法迁移时向供应商确认补丁状态。PHP 官方公告
四、如何完成排查与修复？
1. 确认网站实际使用的 PHP
命令行可以先查看：
php -v
php --ini
这些命令反映的是 CLI 环境。一台服务器可能同时安装多个 PHP 版本，网站通过 FPM、Apache 模块或容器运行的版本可能不同。
继续核对站点配置指向的 FPM 池、主机面板中的站点版本、容器镜像与供应商的软件包记录。托管用户可以请服务商书面确认两个 CVE 均已修复，并已重启对应工作进程。不要把完整 phpinfo() 页面长期暴露在公网。
2. 备份并安装安全更新
先确认文件、数据库和配置备份可恢复，记录当前环境，并安排短维护窗口。优先在同一受支持分支内安装安全更新；跨大版本升级还需要验证插件和扩展兼容性。
以下仅为 Ubuntu/Debian 系 PHP 8.3 + FPM 的示例，包名需按实际安装调整，其他发行版应使用各自的官方更新方式：
sudo apt update
apt-cache policy php8.3-fpm php8.3-cli php8.3-common
sudo apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common
升级前核对候选包是否包含两个 CVE 的补丁，并更新本机其他已安装、仍在使用的 PHP 分支和相关软件包。命令执行成功只说明软件包操作完成，不能直接证明安全修复生效。
如果使用 Docker，需要更新到包含补丁的基础镜像，重新构建应用镜像并替换运行中的容器。只重启旧镜像，或只升级宿主机上的 PHP，无法更新容器内的运行时。
3. 重启承载 PHP 的进程
磁盘上的二进制更新后，旧工作进程可能仍在运行。FPM 环境按实际服务名重启，例如：
sudo systemctl restart php8.3-fpm
sudo systemctl status php8.3-fpm --no-pager
Apache mod_php 应重启 Apache；其他运行方式重启相应服务。多节点环境要覆盖所有实例，包括暂时没有流量的备用实例。Ubuntu 官方也明确提醒，应用更新后通常需要重启才能使用新组件。Ubuntu 官方操作说明
4. 核对运行版本和关键业务
修复后的验收建议保留以下记录：
| 检查项 | 通过标准 |
|---|---|
| 软件包或镜像 | 供应商明确包含两个 CVE 的修复 |
| Web 运行时 | 实际服务请求的进程已使用修复版本 |
| 实例覆盖 | 所有站点、容器与节点均已更新并重启 |
| 网站功能 | 首页、登录、询盘、上传及订单等实际功能正常 |
| 日志与监控 | 没有持续新增的异常退出、内存错误或 5xx 峰值 |
不要在生产站通过公开利用程序验证漏洞。版本、补丁来源、进程状态和业务回归，才是日常修复验收应优先收集的证据。
五、暂时不能升级，如何降低风险？
官方明确说明，只有包含补丁的更新才是完整解决方案。 若短期内无法升级，可以先限制公网访问、在反向代理或网络层设置来源白名单，必要时提供静态维护页。PHP 官方缓解说明
针对已确认的会话相关路径，官方建议在请求解析前生效的 PHP 配置中关闭上传进度并重启全部工作进程：
session.upload_progress.enabled = 0
这只能阻断部分路径，不能修复另一项内存问题，也不能覆盖全部变体。不要依赖应用中的 ini_set() 来完成这项防护。全局状态漏洞说明
内存耗尽路径的临时措施涉及内存限制与前端请求限制，需要运维人员结合容量评估。不要直接照搬 memory_limit=-1：取消 PHP 自身内存限制会改变可用性风险，而且底层分配失败仍可能触发漏洞。WAF 和请求限制可作为额外防线，也不能替代升级。内存漏洞缓解说明
六、怀疑已经被利用，补丁之外还要做什么？
以下是事件排查建议，并不表示出现单一现象就能认定 PHP2Shell 入侵：
- 保留访问日志、PHP 错误日志和主机审计记录，检查异常子进程、陌生外联及文件改动。
- 将异常主机从业务流量中隔离，保留证据后调查新增脚本、计划任务和账号。
- 如果确认主机失陷，从可信镜像或已验证的干净备份恢复，并在干净环境中轮换可能泄露的数据库、部署与第三方服务凭据。
- 补丁上线后继续观察错误率和安全告警，避免只删除一个可疑文件就结束处理。
七、给网站负责人的处理清单
如果网站由外包团队或主机商维护，可以直接要求对方交付四项信息：网站实际 PHP 版本、补丁依据、进程重启记录、关键功能验证结果。只回复“已开防火墙”或“已升级插件”，不足以说明这次问题已解决。
需要协助梳理网站运行环境、安排升级和上线验证，可以联系星源 Web Studio，说明使用的主机、建站系统与当前 PHP 版本，便于确认维护范围。