PHP2Shell 漏洞（CVE-2026-109618、CVE-2026-109619）是什么，怎么检查和修复

持续更新。最后核实： 2026-10-22。各厂商还在陆续发布修复，版本信息请以文中链接的公告为准。

作者 Frankie C. · Mindber 高级市场研究员。通过 Mindber Innovation Index 方法追踪东南亚市场 500 多个 AI/SaaS 工具。

评估方式： 2026 年 10 月 22 日，我们读了 PHP 的两份公告 GHSA-w8hw-w9fx-j79w 和 GHSA-6wmf-4rv5-p3rp、php.net 的公告和 Cloudflare 的分析文章，再用 FrankenPHP 发布说明和 NCSC-NL 的 php2shell 仓库补全细节。Mindber 没有运行任何漏洞利用代码，也没有测试任何服务器。文中命令都是常规运维命令，对应公告要求你检查的项目。

如果你的网站跑在 PHP 上，周三发布的这次安全更新今天就要处理。PHP 引擎里的两个漏洞 CVE-2026-109618 和 CVE-2026-109619，合称 PHP2Shell，能让攻击者不用登录就在网站服务器上执行代码。漏洞在 WordPress、Magento 和 Laravel 的下层，任何插件或框架更新都够不着。修复办法是换上新的 PHP 构建，再重启运行它的工作进程。

我们的判断：凡是跑 Apache + mod_php 的服务器，都按紧急事件处理。PHP 团队正是在这种部署下证实了一次完全不需要应用代码配合的完整攻击。PHP-FPM 网站更难被打，但有一个变种同样在 FPM 上被证实，所以它们应该排进今晚的补丁批次，而不是下周的维护窗口。

现在该做什么

在下表找到你的分支，升级到对应的修复版本，或者安装 Linux 发行版里带同一补丁的软件包。

然后按顺序做四件事：

1. 弄清网站用的是哪个 PHP 构建，以及 Apache 是否以 mod_php 方式加载它。mod_php 服务器优先处理。
2. 安装修复版本。Debian、Ubuntu 或 RHEL 的补丁包可能还显示旧版本号，所以要去更新日志里查 CVE 编号。
3. 重启所有 PHP 工作进程，确认正在运行的版本。不重启，旧代码就一直留在内存里。
4. 如果今天有原因打不了补丁，先用下文的临时配置，并保持 WAF 开启，直到能打为止。

用共享主机的话，前三件事都在主机商手里，请他们书面确认 PHP 是否已升级、工作进程是否已重启。每一步的命令都在后面的补丁部分。

两个漏洞是怎么回事

CVE-2026-109618：内存在最糟糕的时刻耗尽

每个 PHP 请求都有内存预算，也就是 memory_limit。正常情况下，请求一旦超限，PHP 会停止这个请求并做清理。问题出在它停止的方式：PHP 用 C 语言的 longjmp() 直接跳出当前正在执行的代码。如果跳出的那一刻，某段代码手里正握着只初始化了一半的请求内存，后面的清理流程就会把这块内存当成完整数据来读。攻击者只要精心布置好堆内存，就能把这次误读变成代码执行。

失败的那次内存分配甚至不必和这块半成品数据有关，任何一次分配在错误时刻失败都行。所以攻击者真正要做的，是让 PHP 按自己的节奏把内存耗尽。CVE-2026-109618 公告列出了三种办法，全部借助普通的 multipart 表单提交：

• 没有可用 Content-Length 的 multipart 请求，能绕过最初的 post_max_size 检查，然后持续发送数据。
• 一个表单分段可以带任意多个头部，这些头部在 PHP 内部占用的内存远多于传输时的大小。
• 空的文件字段不计入 max_file_uploads，却照样会生成元数据数组，嵌套的字段名还会让工作量成倍增加。

严重程度取决于解析发生在哪里。Apache + mod_php 在应用启动前就解析请求体，所以网站就算没有任何上传表单也一样暴露。PHP 团队已经通过 HTTP 证实：在默认内存和输入限制、常规多进程 prefork 配置下，可以对 mod_php 实现完整的远程代码执行。PHP-FPM 在请求启动失败时会结束该工作进程，堵住了这条早期路径；攻击者需要找一个在请求后段才耗尽内存的应用接口，比如根据用户输入生成超大数组的导入任务。公告仍然认为 FPM 有风险，只是还没有人展示出针对这个漏洞的完整 FPM 利用。FrankenPHP 调用清理流程的方式和 mod_php 一样，公告认为它很可能也受影响。

CVE-2026-109619：上一个请求留下的残留

PHP 工作进程是一个长期运行的进程：处理完一个请求，收拾干净，再处理下一个。它在请求之间保留的东西里有一部分是全局状态，比如错误信息、会话数据和扩展数据。请求运行期间，这些状态的一部分会指向属于该请求的内存。请求结束时，PHP 本应先把这些指针重置，再释放内存。

致命错误可能打断这次收拾。请求中途终止，内存被释放，全局状态却还指着它。同一个进程接手下一个请求时，有些代码在 PHP 重置状态之前就运行了，读到这个失效指针，碰到一块已经不属于任何人的内存。这就是释放后使用（use-after-free），配合事先布置好的堆，就能变成代码执行。所以攻击者需要向同一个工作进程发两个请求：一个留下失效指针，另一个踩上去。

CVE-2026-109619 公告确认了第二个请求"踩上去"的两种方式：

• PHP 应用按请求生效的配置时产生警告。.htaccess 里一条已弃用的指令就能触发，nginx 通过 PHP_VALUE 传进来的错误值也一样。
• 会话上传进度功能。它默认开启，在正常会话初始化之前运行，哪怕你的代码从未调用 session_start()。

在 PHP 8.5 上，如果开启了 fatal_error_backtraces，每次致命错误都会留下回溯状态，针对 mod_php 最有力的已证实利用就来自这里。会话这条路径则在 mod_php 和常规动态 FPM 进程池上都得到了验证。隐藏错误改变不了什么，因为 PHP 在决定是否显示或记录警告之前就已经碰到了残留状态，error_reporting、display_errors 和 @ 运算符都来得太晚。

哪些服务器风险最高

php.net 把范围定为所有处理网页请求的 PHP 安装。PHP 接入网站服务器的方式，决定了你的暴露程度：

看一个假设场景就明白这意味着什么，它照着公告证实的路径来。一家小型 WooCommerce 网店跑在一台装了 Apache、mod_php 和 PHP 8.3.30 的 VPS 上。攻击者一遍遍向首页发送构造好的 multipart POST 请求。PHP 在 WordPress 加载前解析请求体，在最糟糕的时刻耗尽内存，并在清理时破坏了自己的堆内存。工作进程越多、正常流量越大，需要尝试的次数就越多，但公告说这消除不了漏洞条件。一旦得手，攻击者就以网站用户（通常是 www-data）的身份执行命令，wp-config.php 和里面的数据库密码只差一次文件读取，客户记录和支付插件密钥就在旁边。

把同一家网店换到 PHP-FPM 上，攻击就难了。攻击者需要一个会留下残留状态的应用接口，再让第二个请求落到同一个工作进程。难不等于安全：会话那个变种正是在这样的进程池上被证实的。

最难办的是各种设备。NCSC-NL 维护着一份内置 PHP 的产品清单。我们查看时，清单把 QNAP QTS、Palo Alto PAN-OS 和 Panorama、Citrix NetScaler ADC，以及 Check Point 防火墙的 Web 界面标为受影响，pfSense 和 OPNsense 标为已修复。QNAP 的公告 QSA-26-18 列出的是 QTS 6.1.0 以及 QTS 5.2.11 和更早版本，修复版本待公布。防火墙、NAS、楼宇管理系统和各种管理面板，底层常常跑着你没法自己升级的 PHP。在厂商发布修复前，别让它们的管理页面暴露在公网上。

打补丁并确认生效

以下命令假设你有一台可以登录 shell 的 Linux 服务器。把 8.3 换成你自己的分支。顺序很重要。

第 1 步：找出网站实际运行的 PHP 构建

命令行 PHP 和网站用的 PHP 可能不是同一个构建，两个都要查，还要看 Apache 是怎么加载 PHP 的。

php -v                                   # 命令行 PHP
php-fpm8.3 -v                            # Debian / Ubuntu 的 FPM
php-fpm -v                               # RHEL、AlmaLinux、Rocky 的 FPM
apachectl -M 2>/dev/null | grep -i php   # 出现 php_module 即为 mod_php

发行版软件包常常保留旧的上游版本号，再把修复移植进去。比如 Ubuntu 24.04 的 PHP 8.3 软件包显示的版本是 8.3.6。别看版本号，去更新日志里查：

# Debian / Ubuntu
dpkg -l | grep -E 'php[0-9.]*-(common|fpm|cli)|libapache2-mod-php'
apt changelog php8.3-common | grep -m1 -E 'CVE-2026-10961[89]'

# RHEL、AlmaLinux、Rocky
rpm -q --changelog php-common | grep -m1 -E 'CVE-2026-10961[89]'

查到了，说明已安装的软件包包含修复。从外部看，curl -sI https://example.com | grep -i x-powered-by 能显示网站对外公布的版本，OpenAI 开源的 php2shell-checker 做的也是这项检查。没有这个头部不能说明什么，这个工具的说明文档也写明：结果为 UNKNOWN 不代表已修复。

第 2 步：安装修复

# Debian / Ubuntu：升级所有已安装的 PHP 软件包
sudo apt update
sudo apt install --only-upgrade $(dpkg -l | awk '/^ii/ && $2 ~ /php/ {print $2}')

# RHEL、AlmaLinux、Rocky
sudo dnf upgrade --refresh 'php*'

# Docker：基于修复后的标签重新构建，例如 php:8.3.36-apache
docker build --pull -t my-app .

如果 PHP 来自 ondrej/php PPA 或 Remi 这类第三方仓库，更新也来自那个仓库，请确认它已经发布修复版本。FrankenPHP 1.13.2 的 Docker 镜像和静态二进制文件都内置了修复后的 PHP，还修了 FrankenPHP 自身的四个漏洞。Windows 用户可以在 php.net 下载页获取修复后的二进制文件。暂时没法升级的 cPanel EasyApache 4 服务器，可以先用 NCSC-NL 提供的部分缓解脚本。

第 3 步：重启所有工作进程并确认

sudo systemctl restart php8.3-fpm    # PHP-FPM
sudo systemctl restart apache2       # Debian / Ubuntu 上的 mod_php
sudo systemctl restart httpd         # RHEL 系的 mod_php

重启后再跑一遍第 1 步。如果网站开始报 zend_mm_heap corrupted 崩溃，多半是碰上了目前唯一已知的回归问题：其中两个修复版本在垃圾回收碰到读取过属性的 SimpleXMLElement 时可能崩溃。对应 php-src 第 24488 号 issue，现已标记为修复并关闭。为了躲开它而回退版本，会让 PHP2Shell 重新暴露，所以请留在已修复的版本上，等下一个小版本。

第 4 步：今天打不了补丁时

php.net 列出了一些临时措施，能缩小暴露面，但不能让服务器真正安全。把它们写进 php.ini、FPM 进程池或 Apache 配置，不要用 ini_set() 或 FPM 的 .user.ini，改完后重启所有进程。

; CVE-2026-109619
session.upload_progress.enabled = 0
fatal_error_backtraces = 0   ; 仅 PHP 8.5

; CVE-2026-109618
memory_limit = -1            ; 用 php_admin_value 设置，防止应用覆盖
post_max_size = 8M           ; 需要文件上传则设为 32M

每一行都有代价。设了 memory_limit=-1，一个失控的请求就可能吃光服务器内存，所以要加一个只会终止单个工作进程的容器或 cgroup 内存上限。不要用 RLIMIT_AS 或 RLIMIT_DATA，公告说它们反而会触发漏洞路径。让 upload_max_filesize 小于 post_max_size。如果应用从不接收 multipart 上传，就在代理层直接拦掉这类请求，并删掉 .htaccess 和 PHP_VALUE 里按请求生效的已弃用或无效配置。

打完补丁后，session.upload_progress.enabled=0 也可以继续保留，除非你的网站确实靠它显示上传进度。PHP 团队正是这样建议的：用这个功能的网站很少，而攻击者正盯着它找新漏洞。

WAF 可以再多争取一些时间。Cloudflare 的托管规则覆盖免费版，AWS 和微软也为各自的云发布了 WAF 防护指南。不过直接打到源站 IP 的请求会绕开 WAF，补丁还是得打。

打完补丁后要查什么

攻击在补丁发布前就开始了，跑过受影响版本的服务器可能已经有人来过。照样要查。

# PHP 和网站服务器日志里的内存耗尽、超时和致命错误
grep -hE 'Allowed memory size|Maximum execution time|PHP Fatal error' /var/log/apache2/error.log /var/log/php*-fpm.log 2>/dev/null | tail -n 50

# 会话文件里被植入的 PHP 代码
grep -rl '<?php' "$(php -r 'echo ini_get("session.save_path") ?: "/var/lib/php/sessions";')" 2>/dev/null

# 10 月 1 日以来网站目录中新增或改动的 PHP 文件
find /var/www -name '*.php' -newermt '2026-10-01' -ls

# 网站用户当前在运行什么
ps -u www-data -o pid,etime,cmd

同一 IP 集中出现的内存耗尽错误、发往不接受上传的页面的 multipart POST 请求、含有 PHP 代码的会话文件，都值得细查。JUMPSEC 的只读脚本 phpocalypse 会把日志、配置和会话文件打包成一个 ZIP 供分析。检查结果干净也不能当作证明，有些攻击路径只在内存里留下痕迹。

一旦发现可疑迹象，就按入侵事件处理：隔离主机，保留日志，用干净的镜像重建。如果个人数据可能已经外泄，数据泄露通报时限可能适用，尽早找负责法务和隐私的人介入。不管数据有没有外泄，都要更换数据库密码和 API 密钥。

PHP2Shell 已经被利用了吗？

是的。Cloudflare 看到针对其客户的攻击流量，攻击载荷还在不断改写以绕过规则。Amazon 威胁情报团队发布了一份报告，标题是"Amazon Threat Intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot"。官方记录还没跟上：我们查看 CISA 已知被利用漏洞目录（2026.10.21 版）时，两个 CVE 都还没有列入。收录后我们会在这里补上，后续报道见 Mindber 新闻栏目。

这次披露的节奏也比计划快：

这次事件对打补丁的启示

大多数 PHP 团队按计划打补丁：每月一个窗口，先上测试环境，再悄悄发布。PHP2Shell 打乱了这个节奏。细节在计划日期前泄露，利用代码仓库几小时内就出现了，PHP 团队给两个漏洞的 CVSS v4.0 评分都是 9.2，落在严重区间。如果等到下周的维护窗口，服务器就要在已经流传的攻击面前暴露好几天。

所以值得提前准备第二条更快的通道，别等用的时候才搭。它包括三部分：在测试副本上做一次快速兼容性检查，先给暴露最严重的服务器（mod_php）上线，然后确认正在运行的工作进程用的是新构建。磁盘上的软件包更新了，并不能说明进程也换了。最后这一点最常被跳过，上面第 3 步就是为它写的。

速度快，部分原因在于漏洞的发现方式。据 Cloudflare 介绍，这对漏洞由 Calif.io、Wiz、OpenAI 和 Quarkslab 的研究人员报告。Cloudflare 还说，PHP 5.4 及之后的所有版本都受影响，也就是说出问题的代码从 2012 年起就在发布。Wiz 的文章标题是"AI uncovers critical RCE vulnerabilities affecting 70% of the Internet"，OpenAI 也称其模型帮助了研究人员。

OpenAI 在公告里说，披露之前它牵头协调维护者和研究人员已有两个月。来源：OpenAI 的 X 帖子。

被人读了十多年的代码，这次栽在了 AI 智能体手里。它们能盯住一个边界情况，比如内存恰好在某一行耗尽，然后反复测试。攻击者手里也有同样的工具。我们预计，老旧而部署广泛的代码里还会挖出更多这类漏洞，从发现到武器化的周期同样短。快速补丁通道应该在下一次披露之前就准备好，而不是到时候再临时拼凑。

Mindber 相关阅读

• 2026 年 10 月安全更新汇总：同一周 Node.js、NGINX、Go、GitLab 和 eMudhra 的修复，以及先打哪个。
• 东盟 AI 合规指南（英文）：马来西亚、新加坡和菲律宾的数据泄露通报时限。
• 循环工程：AI 智能体如何反复验证一个想法，找到这些漏洞用的也是这种方式。
• Claude Fable 5 暂停服务：Anthropic 为什么只把具备网络攻防能力的 Mythos 5 开放给经过审核的防御人员。
• NVIDIA NemoClaw（英文）：在自己机器上运行 AI 智能体时的基础设施层安全控制。
• Claude Code 和 ChatGPT 里的 Codex 能读取 php.ini、FPM 进程池和 .htaccess，标出公告警告的按请求生效的配置。在生产服务器上只给它们只读权限。
• AI 编程智能体：这类工具在目录里的分类。
• AI Agent 采购指南：主机商替你处理客户数据时，值得追问的数据泄露通报问题。
• 排行榜、发现页、我们的评估方法，以及跟踪工具是否仍在维护的存活检查。

常见问题

延伸阅读

美国政府下令暂停 Claude Fable 5

具备网络攻防能力的 AI 模型如何被纳入出口管制，这对防御方意味着什么。

循环工程 Loop Engineering：顶级工程师为何不再给 AI 写提示词

AI 智能体在循环中自我验证的工作方式，也是这次找漏洞的方式。

PDPA 与 PDPC AI Agent 采购指南（2026）

选供应商时该问的数据处理和泄露通报问题。

本文是对公开信息的分析，不是原创安全研究，Mindber 没有测试任何漏洞利用代码或服务器。所有事实已于 2026 年 10 月 22 日对照上述来源核查。事件仍在发展，最新修复版本请以 PHP 项目和各厂商公告为准。发现错误？告诉我们，我们会在 24 小时内更正。