2026 年 10 月 21 日，PHP 官方打破常规发布周期，紧急发布安全更新，修复两个"严重"（Critical）等级的远程代码执行漏洞——CVE-2026-109618 与 CVE-2026-109619，业界称为"php2shell"。国家信息安全漏洞共享平台（CNVD）已于 10 月 22 日发布风险提示（CNVD-2026-41674、CNVD-2026-41675），加拿大、英国等国家网络安全机构同步发出警报。
一、漏洞概况
| 项目 | 内容 |
|---|---|
| 漏洞名称 | php2shell |
| CVE 编号 | CVE-2026-109618、CVE-2026-109619 |
| CNVD 编号 | CNVD-2026-41674、CNVD-2026-41675 |
| 漏洞类型 | 远程代码执行（RCE），CWE-416 释放后使用（Use-After-Free） |
| 官方评级 | CVSS v4.0 9.2 分（严重） |
| 攻击条件 | 无需身份验证，远程发送构造的 HTTP 请求即可触发 |
| 影响范围 | PHP 5 以来的所有版本；官方仅提供 8.2–8.5 分支修复 |
| 修复版本 | PHP 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 |
| 在野利用 | 截至通告时未发现规模化利用，但细节与 PoC 已公开，窗口有限 |
二、漏洞原理：一条"请求内存"的暗线
两个漏洞的本质，都是 PHP 对"请求内存生命周期"的管理缺陷：
CVE-2026-109618（OOM 处理缺陷）：PHP 在处理内存耗尽（OOM）错误时，会通过 longjmp() 提前退出当前上下文。在某些场景下，请求内存尚未完全初始化便已处于可访问状态，一旦内存分配失败，PHP 未能正确处理这次提前退出，导致请求内存处于无效状态。攻击者可以构造包含大量请求头、嵌套字段名或空文件控件的 multipart 请求，在看似不超过 post_max_size 限制的情况下耗尽 memory_limit，触发 OOM。在 Apache mod_php 等会无条件调用请求关闭流程的运行方式中，关闭流程会处理这些无效状态，最终造成内存破坏和远程代码执行。
CVE-2026-109619（全局状态残留）：PHP 工作进程会保留指向上一个请求内存的全局状态（错误、会话、对象和扩展状态），但在请求内存被释放之前未能完全重置。攻击者通过构造特定请求序列（例如先以致命错误让状态"生产"残留，再由同一进程的后续请求"消费"），形成跨请求的释放后使用（UAF），实现未经认证的远程代码执行。
共同点：攻击者无需任何凭证，仅通过 HTTP 请求即可触发，且依赖同一进程内的请求状态复用——这意味着 PHP-FPM、mod_php 等长驻型运行方式风险最高。仅靠调整工作进程数量无法消除风险。
三、影响范围：比想象的更广
1. 运行方式全覆盖：所有对外提供 Web 服务的 PHP 安装均受影响，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed。其中 mod_php 风险最高——已有公开演示：未经认证的请求可在应用代码执行之前就触发漏洞。CVE-2026-109619 在 PHP-FPM 环境下同样验证成功。
2. 应用层全覆盖：由于缺陷位于 PHP 运行时内核而非某个应用组件，WordPress、Drupal、Joomla、Laravel 及一切以 PHP 承载的 Web 业务——企业官网、商城、论坛、小程序后台、API 接口——全部在影响范围内。网站有登录页、维护页，并不能保护运行时。
3. 版本覆盖面广：PHP 官方确认漏洞自 PHP 5（21 年前已停止维护）以来的所有版本均存在，但仅为受支持的 8.2–8.5 分支提供修复版本；7.4、8.0、8.1 提供了源码级最小回移补丁（需自行编译，且不回归常规支持）；8.1 及更早版本日常已无官方更新。有安全机构扫描发现，互联网上仍有约 88.4 万台对外服务的主机运行 PHP 8.1 及更早版本，约占已反馈版本主机的 59%——这些存量系统是最大的风险敞口。
4. 容器镜像同受影响：Docker 等容器中内置的 PHP 运行时同样中招，需要重建镜像才能修复。
四、事件回顾：一次被提前泄露的协调披露
该漏洞原定于 10 月 22 日协调披露。10 月 20 日，Hacker News 上一条匿名帖子声称 PHP 存在两个 CVSS 10.0 的远程代码执行漏洞、影响 PHP 5 以来所有版本；安全公司 watchTowr 随后证实信息属实（其已复现 CVE-2026-109618），PHP 官方当晚发布提前通告，将安全发布提前至 10 月 21 日 14:00 UTC。官方评级为 CVSS v4.0 9.2 分，与泄露信息中的 10.0 略有出入，但均属"严重"级别。
漏洞发现方公开演示了在运行 Laravel 框架的服务器上，通过构造请求在 38 秒内获得系统命令执行能力；可靠利用需要数千至数万次 HTTP 请求，完全适合自动化攻击。安全研究者 Kevin Beaumont 评价："这将引发一连串安全事件，是近年来最大的漏洞之一。"Cloudflare 已为其 WAF（含免费版用户）部署了已知攻击向量的临时拦截规则，但明确表示这只是权宜之计。截至目前，尚未发现规模化在野利用——但这个窗口不会太长。
五、立即自查：三步确认你的服务器是否受影响
第一步：确认 PHP 版本。服务器命令行执行 php -v（注意：CLI 版本可能与网站实际使用的 Web 版本不同）；宝塔面板用户在"软件商店 → 已安装"中查看 PHP 版本号，或进入网站设置查看当前使用的 PHP 版本；也可以临时放置一个 phpinfo() 页面查看 Web 实际加载的版本（查完请删除）；Docker/容器环境检查基础镜像与容器内 PHP 版本；虚拟主机用户直接联系主机商确认站点所用 PHP 版本及升级计划。
第二步：对照修复版本表。
| PHP 分支 | 受影响版本 | 修复版本 |
|---|---|---|
| 8.5.x | 低于 8.5.12 | 升级至 8.5.12 |
| 8.4.x | 低于 8.4.27 | 升级至 8.4.27 |
| 8.3.x | 低于 8.3.36 | 升级至 8.3.36 |
| 8.2.x | 低于 8.2.35 | 升级至 8.2.35 |
| 8.1 及更早 | 全部受影响 | 无官方修复版本，需迁移或自行编译回移补丁 |
第三步：排查是否已被入侵。重点检查 Web 服务器与 PHP 进程日志，关注以下痕迹：
- PHP 工作进程（php-fpm、httpd、apache2）派生的异常子进程：sh/bash/cmd.exe/powershell、python/perl、curl/wget/nc 等；
- 网站目录（尤其是临时目录、上传目录）中出现可疑的 PHP 文件（Webshell）；
- 可疑外联、反弹 shell 特征（/dev/tcp/、fsockopen、mkfifo）以及 whoami、id、uname -a 等侦察命令记录。
如发现异常，应立即下线处置并寻求专业支持，不要只升级了事。
六、修复方案：升级是唯一彻底的解法
1. 立即升级（推荐）：将 PHP 升级至对应分支的安全版本（8.5.12 / 8.4.27 / 8.3.36 / 8.2.35），重启 PHP 服务；容器环境需拉取新版基础镜像重建（docker compose pull && docker compose up -d）。升级后通过 phpinfo 或 php -v 复核版本，并全站测试业务功能。
2. 版本选型建议：PHP 8.2 将在 2026 年底停止维护，8.3 至少维护到 2027 年底；追求最长维护周期，建议直接升级到 8.5.12。运行 8.1 及更早版本的站点，应借此机会迁移到受支持分支。
3. 虚拟主机/云主机用户：联系主机服务商确认其升级时间表；若对方短期无法处理，考虑迁移到支持自主升级的环境。
4. 实在无法立即升级时的临时缓解措施（官方明确提示：只是"临时拐杖"，不能替代补丁）：
- CVE-2026-109618：将 memory_limit 设为 -1 且不允许应用覆盖（如 FPM 池的 php_admin_value）；调低 post_max_size（无上传需求设 8M，有上传设 32M）；在 Web 服务器/代理层限制请求体大小、字段数、multipart 分块数、请求头数量与嵌套深度；使用容器/cgroup 限制资源（勿用 RLIMIT_AS/RLIMIT_DATA）。
- CVE-2026-109619：关闭 session.upload_progress（session.upload_progress.enabled=0）并重启所有工作进程；PHP 8.5 另设 fatal_error_backtraces=0。
- 通用：调低 FPM 的 pm.max_requests；开启 SELinux/AppArmor；设置 expose_php=0；有 WAF 的开启虚拟补丁；必要时将对外服务临时隔离。
5. 升级兼容性提醒：PHP 大版本跳跃可能带来代码兼容问题，建议先在测试环境验证，由熟悉业务的技术人员操作，避免"为修一个漏洞，弄坏整个网站"。
七、给企业负责人的几句实话
- 这类核心层漏洞不挑 CMS、不挑框架，不要有"我用的是小众系统/后台有密码"的侥幸心理；
- 更新 WordPress 插件、执行 composer update 不等于更新 PHP 运行时，补丁要打在运行时上；
- 多年未动、无人维护的老站点最危险，也最该趁这次机会做一次彻底的安全体检；
- 如果自己拿不准服务器状态，交给专业的人做，成本远低于一次入侵事故——服务器被控意味着数据泄露、网页挂马、品牌受损，甚至沦为攻击他人的跳板。
八、写在最后：安全升级，可以交给专业的人
作为郑州本地深耕网站建设与运维的服务团队，河南卫民网络已对客户托管与自营站点启动 PHP 版本安全排查，并可对外提供：PHP 版本升级与兼容性处理（含老站点 7.x/8.0/8.1 迁移至受支持分支）、服务器安全自查（版本核对、配置加固、入侵痕迹排查）、网站年度托管与代维（安全补丁跟进、日常巡检、故障应急响应）。
如果您的网站恰好跑在 PHP 上，又没把握自己完成这次紧急升级，欢迎联系我们协助处理。7×24 小时售后热线：400-671-2014；业务电话/微信：15515834913、18569914411。
信息来源：PHP 官方安全通告（php.net，2026-10-21）、国家信息安全漏洞共享平台 CNVD（CNVD-2026-41674/41675）、加拿大国家网络安全中心 AL26-026、英国 NCSC，以及 Help Net Security、heise security 等公开报道整理。文中数据以官方发布为准，请以 php.net 最新信息为最终依据。