PHP2Shell 漏洞分析：CVSS 9.2 的 PHP 核心引擎 RCE，与我们 9 小时的应急升级

2026 年 10 月 21 日，PHP 官方紧急发布了两个 CVSS 9.2 的核心引擎漏洞补丁（CVE-2026-109618、CVE-2026-109619），统称 PHP2Shell。

它的可怕之处不在于复杂度，而在于位置——漏洞在 PHP 本身，不在 WordPress、不在 Joomla、不在你写的任何一行业务代码里。只要服务器上的 PHP 版本低于补丁版本，哪怕首页只是一个「Hello World」，也在射程之内。

如果你是网站运营者，下面的判断只需要 30 秒：

升级完成后必须重启 PHP-FPM、Apache、以及任何常驻的 PHP 进程。只换文件不重启 worker，等于没升级——这个漏洞的利用链跨请求，旧 worker 里的脏状态还在。

一、漏洞来源

这是本次事件里最值得单独讲的一段，因为它揭示了未来漏洞研究的形态。

漏洞由三家机构独立且交叉地发现并上报：

• Wiz Research（Google 旗下云安全公司）：使用内部 AI 平台 Wiz Atlas，配合 Gemini 4 Argon、GPT-5.6 Sol 模型，于 2026 年 8 月 19 日发现第一个 PHP 漏洞，8 月 20 日、21 日先后在 Drupal 和 WordPress 上验证了未授权 RCE。
• Calif（安全研究机构）：借助 OpenAI 的 GPT-5.6 Sol 模型，于 7 月 30 日启动审计，8 月 11 日由研究员 Ryan A 报告了无条件远程代码执行。
• OpenAI Codex Security（含研究员 Amy Burnett）：同日独立报告了同一根因。

GitHub 安全公告（GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp）的致谢名单中列出的上报者为 lcfr-hax、sagitzadik-wiz、tomash-areion、amyb-oai；负责修复开发的是 PHP 核心维护者 bukka（Jakub Zelenka）、arnaud-lb（Arnaud Le Blanc）、iluuu1994（Ilija Tovilo）、ndossche（Niels Dossche）。

时间线完整还原如下：

值得一提的是，据 PHP 基金会说明，更早的线索可追溯到 2024 年由 OSTIF 组织的 Quarkslab 代码审计，但因兼容性取舍复杂、专职人手有限，完整修复被一再推迟。也就是说——这个洞不是没人看见，是没人相信它真能被利用。直到 AI 把「几乎不可能」的利用链压缩到了一个人一周的工作量。

这些发现是 PHP 中最严重的漏洞之一，也许是有史以来最严重的软件漏洞之一。底层缺陷已经存在了几十年，但要证明其可利用性需要一条异常复杂的链路，已经逼近人类研究者实际能力的边缘。

—— Wiz Research

二、风险等级：CVSS 9.2，但 9.2 低估了它的传播性

两个 CVE 的 CVSS v4.0 评分均为 9.2（Critical）。拆开基向量看：

CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N

这里有个必须讲清的细节：攻击复杂度标的是「高」（AC:H），但这不代表「安全」。

AC:H 反映的是攻击者需要反复调试、适配目标内存布局——这是人类研究者的门槛。而 AI 恰恰拆掉了这道门槛。Wiz 描述说，过去需要世界级团队数月的工作，现在单个研究者用一周就完成了；针对不同应用的可用 exploit，可在数小时内开发并适配。

攻击复杂度是一个会随时间衰减的指标，而 CVSS 只是快照。补丁发布当天就有安全厂商在传感器上观测到在野尝试，这个衰减速度比历史上任何一次都快。

更要警惕的是 PR:N 与 UI:N 的组合——不需要任何账号、任何凭据、任何受害者配合。配合 AV:N，这意味着互联网上任何一个人都能发起尝试。

三、可能的破坏：两种风险，第二种比第一种更阴

风险一：直接拿下服务器

攻击者以 Web 服务进程的身份（通常是 www-data、nginx、apache）执行任意代码。后果链条是：

1. 植入后门 / Webshell，获得持久化访问；
2. 篡改网站内容，把企业官网变成钓鱼页、博彩页、恶意软件分发站——用的是你积累多年的域名信誉；
3. 横向移动：读取 .env、wp-config.php、数据库连接串，跳到内网；
4. 挖矿 / 加入僵尸网络，消耗服务器资源；
5. 窃取全部业务数据，包括客户订单、会员信息。

PHP 官方认为 mod_php 部署的风险最高，因为已有演示证明，单个未认证请求可以在任何应用代码运行之前就触发攻击。也就是说，应用层的一切防护——安全插件、WAF 规则、登录加固——在这条路径上都不参与。

风险二：不拿代码执行权，只读内存

这是本次漏洞里更被低估的一半。攻击者可以在不获得任何代码执行权限的前提下，读取 PHP worker 进程的内存。

那段内存里有什么？PHP-FPM 的 worker 是复用的——同一个 worker 可能刚刚处理完 A 用户的登录请求，紧接着处理 B 攻击者的请求。A 用户的密码明文、Session Token、API Key、证书私钥，很可能还躺在被复用内存的某个角落。

Wiz 特别强调：这个内存泄露是应用无关的——在受害应用从不调用 session_start() 的情况下依然成立。攻击者可以在自己完全无法控制的应用上，读出属于别人的数据。

这和不设防的共享主机、共用 worker 池的虚拟主机环境叠加时，破坏力呈指数级放大：你付了钱、买了独立域名、装了安全插件，但你和隔壁邻居共用一个 PHP worker 池。

Wiz 把 PHP2Shell 与 2014 年的 Heartbleed、2021 年的 Log4Shell 相提并论，指的就是这个「共享基础设施被击穿」的性质。

已经在被尝试利用了

需要客观说明：截至目前，没有公开证据表明存在大规模成功入侵的统计。但同样客观的是：

• Cloudflare CTO Dane Knecht 在补丁发布当天表示「我们正在看到早期攻击出现」，并已为所有客户（含免费版）部署了针对已知利用向量的 WAF 规则；
• 攻击面管理公司 watchTowr 表示补丁发布后立即在其传感器上观察到首批在野利用尝试（未确认成功）；
• 检测响应厂商 Expel 指出，称可 exploit 这些漏洞的代码已在流传，且部分可能本身就是恶意样本——不要下载、不要运行来源不明的 PoC。

结论很直接：窗口期只有几天，甚至几小时。而「没有确认成功入侵」这句话，对已经被攻破的服务器毫无安慰作用——因为正如后文所述，这类攻击在应用日志里可能什么痕迹都不留。

四、影响范围：全球70%网站

影响的是哪个组件

关键点必须重复三遍：漏洞在 PHP 引擎，不在应用。

技术根因是 PHP 在处理请求的致命错误（尤其是内存耗尽，OOM）路径上存在设计缺陷：OOM 时 PHP 使用 longjmp() 跳出上下文，导致请求数据在仅完成部分初始化、或已被释放的状态下被留在全局状态里。随后同一个 worker 处理的下一个请求复用了这块「陈旧状态」，形成 use-after-free 与类型混淆。

由此推出一个很多人会踩的坑：升级 WordPress、升级主题插件、加装安全插件，统统没有用。你必须升级服务器上的 PHP 运行时。TLS 加密再完整、WAF 规则再严格，也拦不住在请求解析阶段、应用代码运行之前就发生的内存破坏。

具体受影响的技术栈

PHP 官方公告明确列出的 SAPI（Server API）全部在影响范围内：

说明：PHP-FPM 在请求启动阶段失败时会直接退出子进程，因此 CVE-2026-109618 暂无完整的 FPM 利用演示；但源码分析支持其易感，不能据此认为 FPM 环境安全。

受影响的知名开源项目

必须说清因果关系：这些项目不是「自己出了漏洞」，而是它们全都运行在 PHP 上，因而全部暴露。Wiz 与 Calif 在以下项目上完成了未授权远程代码执行的实证演示或确认：

说明：Calif 所列版本号为其测试时的具体版本，请以官方公告为准。但结论不变——底层暴露由 PHP 版本决定，与应用版本无关。Calif 同时报告，某些场景下任意 PHP 脚本亦可被利用。

这张表最值得注意的不是长度，而是它的分布：CMS、电商、框架、运维面板、邮件系统、计费系统。一个覆盖整个 Web 技术栈的横向切片。这也解释了为什么 Automattic（WordPress 母公司）、Cloudflare、AWS、Google Cloud、Microsoft、Akamai、Fastly、Imperva、Vercel 等厂商在披露前就一起参与了缓解方案准备。

版本影响面与日志盲区

版本影响的广度同样触目：

• 几乎所有 PHP 版本都至少受其中一个漏洞影响，最远可回溯到 PHP 5.4；
• 按 Wiz 的说法，过去十年发布的每一个 PHP 版本都在受影响范围内；
• 按 W3Techs 统计，PHP 覆盖约 69% 已知服务端语言的网站，Wiz 口径为 70%。

这意味着，这不是「某个行业的风险」，而是整个 Web 的地基问题。共享主机、虚拟主机、面板托管环境（宝塔、cPanel、Plesk 等集成的 PHP 环境）、Docker 官方镜像、CI 构建出的生产容器——每一层都可能带着旧版 PHP 被部署出去。

还有一个少有人提但极其危险的盲区：因为漏洞执行在应用层之下，应用日志常常记录不到有效信息。Wiz 给出的排查信号是行为层面的：

• 异常的 multipart 请求，紧跟 memory_limit 耗尽报错或反复的 HTTP 500；
• 返回的 PHPSESSID Cookie 异常巨大或格式畸形；
• PHP worker 进程数量出现无法解释的波动（churn）。

看到这些信号不代表一定被入侵，但没看到日志，也绝不等于安全。这是本次事件里最危险的心理陷阱。

五、版本升级：官方怎么说，实际怎么做

官方发布的补丁版本（2026-10-21）

PHP 官方公告的原话是：「不存在完整的缓解措施，更新是唯一安全的选择。」这句话在每一个分支的发布公告里都重复出现了一次。

8.2 及以上：直接升级到最新分支版本

这是绝大多数生产环境应该走的路。升级路径很直白：

• 8.2 分支 → 8.2.35
• 8.3 分支 → 8.3.36
• 8.4 分支 → 8.4.27
• 8.5 分支 → 8.5.12

8.2 用户请特别留意：PHP 8.2 将于 2026 年 12 月 31 日终止支持（EOL），此后不再获得任何安全修复。8.2.35 很可能是 8.2 分支最后一个吃到安全补丁的版本。如果你现在还在 8.2 上，这次升级的同时就应该把迁移到 8.3 或 8.4 排进日程——不是「有空再说」，是「这个季度内」。

低于 8.2：没有官方补丁，必须尽快切换版本

这里必须精确表述，避免误导。

官方确实为 7.4、8.0、8.1 三个已停止支持的分支提供了最小化的源码级回移补丁（对应 Git 分支 PHP-7.4-CVE-2026-109618-109619、PHP-8.0-CVE-2026-109618-109619、PHP-8.1-CVE-2026-109618-109619）。但 PHP 官方对这批补丁的定位写得很清楚：它们是为了「帮助从源码构建、或无法获得 LTS 厂商支持的人」。

它的实际可用性对普通生产环境极低：

• 不是正式发布版本，没有官方二进制包，没有 Windows 构建；
• 不进入任何自动更新通道，宝塔、cPanel 等面板的「软件商店」里不会有；
• 需要自行拉取分支、配置编译参数、重新编译并替换，过程中任何扩展兼容问题都要自己承担。

所以结论不变：低于 8.2 的环境，唯一的正解是尽快切换（升级）到 8.2 以上的受支持分支。不要再指望给 7.4 打补丁续命——那样的系统在本次事件之后，还会有下一个、下下个洞。8.1 及更早版本已经拿不到官方的常规安全修复，这是既定事实，不是这次才有的。

另外补充一点发行版与 LTS 的情况：Debian、Ubuntu、RHEL、Rocky、AlmaLinux 等发行商提前拿到了补丁，发行版包中的 PHP 可能「版本号看着很旧，但已含修复」。这部分用户不需要切分支，只需要确认发行商的安全更新已经安装。

发行版与面板环境的判断方法

这里有一个非常常见的误区：php -v 显示的版本号可能仍是 8.1.x 甚至 7.4.x，但发行商已经把修复回移进了这些包。

判断依据不是版本号，是发行商的安全公告。Debian / Ubuntu 环境检查：

# 查看可升级的 PHP 相关包
apt list --upgradable 2>/dev/null | grep -i php

# 查看已安装 PHP 包的具体版本与来源
dpkg -l | grep -E 'php[0-9.]*-fpm|libapache2-mod-php'

RHEL 系环境检查：

dnf check-update --security | grep -i php
rpm -qa | grep -E '^php'

官方还特别点名了一个来源：rpms.remirepo.net（Remi 第三方仓库）在发布当日不提供更新，依赖它的用户应改用发行版官方包或从源码构建，以便立即应用补丁。

用宝塔面板或其他面板的同学请注意：不要只信面板首页显示的版本号，面板可能展示的是编译时的版本字符串。请在终端实际执行 php -v，并确认 php-fpm 服务确实已重启、phpinfo() 中的 Loaded Configuration File 指向你正在使用的那份配置——一台服务器上装了两三个 PHP 版本、站点实际用错版本的情况非常普遍。

升级动作清单

# 以 PHP 8.3 分支为例（具体命令请按你的发行版与安装方式调整）

# 1. 备份当前 PHP 配置
tar czf /root/php-config-backup-$(date +%F).tar.gz /etc/php/

# 2. 升级到含修复的最新分支版本
#    Debian/Ubuntu（使用发行版源或 sury 源）：
apt update && apt install --only-upgrade php8.3-fpm php8.3-cli php8.3-common

# 3. 确认版本号已变更
php -v

# 4. 重启所有 PHP 相关服务（这一步不能省）
systemctl restart php8.3-fpm
systemctl restart apache2   # 若使用 mod_php
systemctl restart nginx     # 若 Nginx 前置

# 5. 确认全部 worker 都是新进程
ps -eo pid,lstart,cmd | grep php-fpm

第 5 步是最关键、也最容易被跳过的一步。判断标准不是 systemctl status 显示 active，而是每一个 worker 的启动时间都应该是刚才。只要还有一个旧 worker 活着，它身上就还带着可被利用的脏状态。重启后建议再观察一次 phpinfo() 输出，确认实际运行的版本与配置路径。

升不了时的临时缓解

官方给了降级方案，但同时强调：「以下措施降低了对特定攻击路径的暴露，但并不能使安装变得安全。」

针对 CVE-2026-109618（OOM 破坏）：

• 通过 php_admin_value 等应用不可覆盖的方式设置 memory_limit=-1，移除每请求的内存上限，让可预测的 OOM 不再发生——并逐一确认没有池、目录或应用配置把上限又加回来；
• 收紧 post_max_size（无上传需求设 8M，有上传设 32M），保持 upload_max_filesize 低于该值；
• 在 Web 服务器或代理层限制：解码后的请求体大小、输入变量数、multipart 分段数、单段 header 数量、嵌套深度；
• 不要使用 RLIMIT_AS 或 RLIMIT_DATA——它们会让 mmap() 在达到限制时失败，反而触发有漏洞的 longjmp() 路径。

针对 CVE-2026-109619（陈旧全局状态）：

• 设置 session.upload_progress.enabled=0，重启所有 worker（必须在请求解析前生效，ini_set() 或 .user.ini 无效）；
• PHP 8.5 上设置 fatal_error_backtraces=0；
• 清理那些每次请求都会发出诊断信息的无效或废弃配置；
• 修复攻击者可触达的致命错误与执行超时问题。

请把这些临时措施理解成止血带：能延缓失血，但伤口还在，而且它们只堵住了已知的几条路径，官方明确表示同一个根因下还有其它变体。补丁是唯一的缝合方案。

六、云策团队的处置：22 日上午 9 点，全部完成

我们是在 10 月 21 日深夜看到 PHP 官方公告的。

做这行十四年，见过太多次「高危漏洞」。大部分时候，你还有几天甚至几周的缓冲。但这次不一样：CVSS 9.2，PR:N 无需任何权限，AV:N 网络直达，漏洞在 PHP 引擎本身，细节在补丁发布前就已经在互联网上传开，Cloudflare 和 watchTowr 当天就观测到了在野尝试。

这意味着缓冲期不是几天，是几小时。

所以我们没有等到上班时间，也没有先发一份「请注意风险」的提醒了事。2026 年 10 月 22 日上午 9 点，我们完成了所有在保客户项目的 PHP 运行时安全升级与 worker 重启验证。

这件事具体拆开是六步：

1. 当晚全量盘点：逐台核对在保项目的 PHP 版本与 SAPI 类型，mod_php 部署列为最高优先；
2. 配置快照：升级前对 php.ini、FPM pool 配置、站点 conf 完整备份，确保任何异常可在十分钟内回滚；
3. 分支升级：8.2 升至 8.2.35、8.3 升至 8.3.36、8.4 升至 8.4.27；仍在 8.1 及以下的同步推动切换；
4. 重启与验证：重启 FPM / Apache / Nginx，用 ps 核验全部 worker 启动时间为升级后，而非只看服务状态；
5. 业务回归：逐一回归登录、下单、表单提交、文件上传——OOM 相关配置有变动，上传链路必须实测；
6. 线上版本核验：用临时校验页确认线上实际运行的 PHP 版本与配置路径，页面用后立即删除。

到 22 日上午 9 点，所有在保项目完成升级，并逐一验证了可用性。我们没有让任何一个客户带着已知的、可被未认证攻击者远程利用的口子过夜。

为什么我们这次这么急

不是因为怕担责，而是因为我们真的理解这次漏洞意味着什么。

我们给客户做的 WordPress 站，装了安全插件、配了 WAF、禁用了后台文件编辑、改了登录地址——这些都对，也都该做。但 PHP2Shell 告诉我们一个更冷的事实：这些防护全部发生在应用层，而这个漏洞在应用层之下。

一个安全插件拦不住一次 PHP 引擎级别的 use-after-free。一条 WAF 规则也挡不住通过 multipart 请求在请求解析阶段触发的内存耗尽。修补它的唯一位置，是那行 php -v 输出的版本号。

所以我们一直说，WordPress 建站从来不只是「装个主题、拖个 Elementor」。真正决定一个站点能活多久的，是这些没人愿意看的东西：PHP 版本、内核版本、日志轮转、备份策略、FPM 的 max_children 是否匹配内存。这些东西不出问题时是零价值的，出问题时是全部价值。

我们如何看待「安全」这件事

这次事件之后，我们把下面几条写进了对客户的承诺里，也写进了自己的运维手册：

1. 安全不是一个插件，是一条运维纪律。装了什么插件只能说明你花了钱，PHP 版本和补丁节奏才说明你在管事。
2. 披露当天就是处置当天。不做「明天上班再看」，不做「先观察一下」。严重级别的核心组件漏洞，我们的响应窗口是小时级，不是天级。
3. 先动手，再汇报。客户不需要在凌晨读一份风险评估，客户需要早上打开网站时它是安全的。告知可以晚一点，处置不能晚。
4. 升级必须可回滚。所有变更前先做完整快照，这是我们敢在深夜动手的前提，也是对客户业务最基本的尊重。
5. 验证到进程级，而不是状态级。服务显示 active 不代表 worker 是新的，配置改过不代表生效。我们会一直验证到「这个进程是什么时候起来的」这一层。

如果你不在我们的在保名单里

坦白讲，这次事件的暴露面太广，我们不可能覆盖所有人。如果你是我们的老客户但已过保，或者你在别处有站点，请把下面三句话转给你的技术负责人：

1. 今天就去服务器上执行 php -v，看版本号；
2. 低于 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 对应分支的，立刻升级并重启 worker；
3. 如果拿不准有没有被利用过，不要只看应用日志——按前面 Wiz 给的三个信号去查访问日志和进程行为，必要时保留现场再处理。

我们也欢迎你直接把服务器版本信息发给我们，帮你判断需不需要动。这种事没什么好藏着的，问一句比赌一把便宜得多。

七、这件事对我们行业意味着什么

我倾向于认为，PHP2Shell 会成为一个分水岭，就像 2014 年的 Heartbleed 和 2021 年的 Log4Shell。

它第一次让所有人清楚看到：AI 已经让「理论上存在但实际无法利用」这句话失效了。那个被 Quarkslab 在 2024 年审计中看到、却因为「太难利用」而被搁置的缺陷，在 2026 年被一个人用一周时间变成了可用的 exploit。下一次，可能是任何一个被业界认为「风险可接受」的历史遗留问题。

Wiz 自己也在结论里承认这一点：发现与利用的经济学都变了。曾经看起来不切实际的漏洞，正在变成可行的攻击目标；而同样的能力也给了防御方一次机会，去系统性排查那些熬过了多年审视的缺陷。

对运维和建站服务商而言，结论很朴素：

• PHP 版本应该是一个被持续监控的资产，而不是「当初装的时候是多少就是多少」；
• 不能再把「没有人会去打这个」当作安全假设；
• 应急响应能力——能否在 12 小时内完成一轮全量升级——会逐渐成为服务商的核心竞争力之一。

我们已经把这次的处置流程整理进了运维手册，包含版本盘点脚本、升级前快照、worker 重启验证和上传链路回归清单。下一个这样的夜晚，我们希望做到的，不是「更快地救火」，而是「根本不在火场里」。

安全这件事没有终点，只有节奏。我们把节奏保持在补丁发布的那一天。

附录：核心事实来源

• 漏洞技术细节、AI 发现过程、披露时间线、演示目标：Wiz Research 博客，2026 年 10 月 21 日
• 影响版本、修复版本、缓解措施、SAPI 风险评级：PHP 官方安全公告，2026 年 10 月 21 日
• 贡献者署名、CVSS 向量、受影响与修复版本区间：GitHub Advisory GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp
• 各应用上的实证演示版本号：Calif 研究报告（经 Unite.AI 2026-10-21 转述）
• 在野利用观测、WAF 规则部署：Cloudflare CTO Dane Knecht 公开表态；watchTowr；Expel 分析，2026 年 10 月 21 日
• PHP 网站份额统计：W3Techs（约 69%，已知服务端语言口径）
• 2024 年 Quarkslab 审计线索：PHP 基金会披露说明

免责说明：本文技术结论均基于上述公开一手资料整理，截止 2026 年 10 月 22 日上午。漏洞利用态势仍在快速演变，处置前请以 PHP 官方公告与所在发行商安全公告的最新内容为准。文中涉及的具体应用版本号为各研究机构测试时所用版本，不代表其唯一的受影响版本。