21CTO导读：本文为修复PHP2Shell 严重安全漏洞的实用指南。

PHP2Shell 指的是 PHP 本身存在的两个严重远程代码执行 (RCE) 漏洞，分别为 CVE-2026-109618 和 CVE-2026-109619。

这两个漏洞在通用漏洞评分系统 (CVSS) v4.0 中的得分均为 9.2 分，任何一个漏洞都可能允许未经身份验证的攻击者在处理 PHP 请求的服务器上执行代码。

Cloudflare表示，这些漏洞已被黑客们利用。

PHP 小组于 10 月 21 日发布了8.5.12、8.4.27、8.3.36 和 8.2.35 版本的修复程序。如果你在技术栈中运行了 PHP，请立即更新。如果你将 PHP 部署在容器中，Aikido 发布了免费的已打补丁的 PHP 镜像，这些镜像可以继续使用当前的 PHP 版本，并将修复程序移植到其他版本。

将 PHP 更新到修复版本

更新是唯一彻底的解决方法是更新至 PHP 8.5.12、8.4.27、8.3.36 或 8.2.35 版本，然后重启所有 PHP 进程并重建所有容器镜像。

仅修补正在运行的容器会导致镜像暴露。更新后，请保留 `` session.upload_progress.enabled=0。这是一个很少使用的遗留功能，也是已知的 CVE-2026-109619 漏洞的入侵途径之一，因此即使在已打补丁的系统中，禁用它也能消除该漏洞。请在 ``（一个php.ini在请求解析之前应用的 PHP-FPM 池或服务器配置）中设置它，然后重启所有工作进程。

使用修补过的Aikido镜像

已打补丁的Aikido 镜像（Aikido Images ）可在Aikido 公共 Amazon Elastic Container Registry (ECR)上免费获取。请在下表中选择分支，然后拉取你使用的变体中的最新补丁，例如 ` public.ecr.aws/aikido-dev/php:8.5.12-fpm`。基础变体是纯文本标签，例如 ` php:8.2.35`。

如果上游没有修复程序，Aikido Images 会将修复程序移植到你已运行的版本中，以便标签保持其版本号。

更多镜像还在准备中，你可直接更新到已修复的 PHP 版本。

通过操作系统或供应商进行更新

Linux 发行版和长期支持 (LTS) 供应商已提前收到补丁，因此请先检查供应商是否有更新的软件包。

PHP 官方公告称，由志愿者维护的 Remi 代码仓库 (rpms.remirepo.net) 尚未更新。请及时查看其当前状态，或切换到发行版软件包，或从源代码构建。

如果运行的是 PHP 8.1 或更早版本

PHP 项目已停止为这些版本提供更新。请升级到受支持的版本，或联系你的服务器供应商获取向后移植的修复程序。PHP 安全团队还发布了 7.4、8.0 和 8.1 的最小源代码向后移植版本，供从源代码构建的团队使用。Aikido Images 涵盖了 7.x 系列以及 PHP 5.5 和 5.6（参见上表）。

PHP 8.2 将于 2026 年 12 月 31 日停止维护，因此请计划迁移到受支持的分支。

如何验证 PHP 安装是否已打补丁

确认处理 Web 请求的运行时环境是已打补丁的版本。

1. 使用公共工具检测。Aikido的免费 PHP2Shell 检测器会报告网站是否存在漏洞、已采取缓解措施还是已打补丁。
2. 查找所有 PHP 安装。包括并行 PHP 分支、容器、持续集成和持续交付 (CI/CD) 镜像、cPanel 、宝塔和 Plesk 等主机面板，以及供应商软件或 Windowsphp.exe和php-cgi.exe二进制文件中捆绑的 PHP。
3. 不要只相信php -v。它报告的是命令行二进制文件，这可能与为你的网站提供服务的 PHP-FPM 或 Apache 模块不同。
4. 查看厂商变更日志以获取 CVE ID。将软件包名称替换为您自己的软件包名称

apt changelog php8.3-cli | grep -E "CVE-2026-109618|CVE-2026-109619"

RHEL、Rocky Linux 或 AlmaLinux：

rpm -q php-cli --changelog | grep -E "CVE-2026-109618|CVE-2026-109619"

5. 重启或替换所有工作进程。重启 PHP-FPM、Apache 和所有应用程序工作进程，或者重新部署容器，然后确认没有工作进程仍在运行旧版本。
6. Aikido 镜像：请使用上面表格中列出的适用于你所在分支的最新补丁。
7. 恢复紧急设置，但保持上传进度关闭。如果你已应用临时缓解措施，请恢复php.ini中原值的memory_limit，并在确认补丁运行后检查所有上传限制。保持session.upload_progress.enabled=0原样即可。

如果无法立即更新

这些措施可以降低特定攻击路径带来的风险，但并不能保证系统绝对安全，而且每项措施仅针对一个漏洞。PHP的安全公告中列出了所有漏洞。

针对 CVE-2026-109618：

• 设置内存限制memory_limit=-1，应确保应用程序无法覆盖此限制，例如php_admin_value在 PHP-FPM 内存池或 Apache 配置中。然后确认没有任何内存池、目录或应用程序设置能够恢复有限的内存限制。这样可以消除攻击者能够控制的内存限制故障，但底层内存分配故障仍然可能影响到存在漏洞的代码，并且由于没有上限，失控的请求可能会耗尽服务器资源。
• post_max_size参数。如果你的应用程序不需要文件上传，请设置一个较低的值：8M；或者是 32M。务必保持upload_max_filesize在较低值以下。此外，还应在 Web 服务器或代理上强制执行请求大小、字段数、multipart/part 部分数、标头数和嵌套限制，包括对于没有可用参数的请求Content-Length。
• 使用容器或 cgroup 的内存限制作为可用性边界，理想情况下，该限制应仅终止受影响的工作进程。不要使用RLIMIT_AS`或` RLIMIT_DATA，因为它们可能会触发易受攻击的内存分配失败。

针对 CVE-2026-109619：

• session.upload_progress.enabled=0。在 PHP-FPM 进程池或服务器配置中设置此参数，该配置会在请求解析之前生效，然后重启所有工作进程。不要依赖 `--session-path`或ini_set()以及user.ini中的`--session-path` 。这能阻止已确认的会话路径，但不会阻止其他变体。
• 在 PHP 8.5 中，设置fatal_error_backtraces=0并重启每个 worker。这会阻塞已确认的致命错误回溯路径。
• 移除初始化前发出诊断信息的无效或已弃用的每次请求设置。隐藏错误消息error_reporting，以及display_errors为0，以及不要用@符号。
  

如果你的应用程序不使用分段上传，请在 POST 请求到达 PHP 之前阻止multipart/form-data。

打完补丁后：检查是否存在安全漏洞

查找异常的请求，以及随后出现的内存限制错误或重复的 HTTP 500 响应，并检查PHPSESSID响应中是否存在过大或格式错误的 Cookie。然后检查是否存在 Web Shell、意外文件、新管理员用户、已修改的 PHP 文件、PHP 或 Web 服务器生成的意外子进程，以及异常的出站连接。

代码执行会使攻击者获得 PHP 进程可以读取的所有信息，包括数据库凭据和 API 密钥。如果怀疑系统遭到入侵，请立即在受影响的系统上轮换修改和使用密钥。

PHP 基金会和安全社区合作，会发布和推出更多的修复指南。PHP的安全公告包含了完整的技术细节。

https://www.php.net/archive/2026.php#2026-10-21-5

作者：场长