检测我的网站

所有文章

php2shell：PHP 的两个严重漏洞已修复，请今天就更新网站的 PHP

PHP 8.5.12、8.4.27、8.3.36 和 8.2.35 修复了 CVE-2026-109618 和 CVE-2026-109619，这是两个无需登录即可远程执行代码的漏洞。谁受影响，如何查看 PHP 版本，现在该做什么。

Radek，ENSOMEDIA发布于 7 分钟阅读In EnglishPo polskuAuf DeutschEn españolEn françaisبالعربية

2026 年 10 月 21 日，PHP 项目发布了 PHP 8.5.12、8.4.27、8.3.36 和 8.2.35。它们修复了两个严重漏洞 CVE-2026-109618 和 CVE-2026-109619，攻击者可能无需登录就在网站服务器上运行代码。PHP 团队表示，所有 PHP 用户都应立即更新（php.net）。

如果你的网站运行在 WordPress、WooCommerce、Joomla、Drupal 或任何其他 PHP 软件上，这件事与你有关。漏洞出在 PHP 本身，不在 WordPress 或某个插件里，所以更新 WordPress 并不能修复。必须更新 PHP，通常由你的主机商来做。

发生了什么

  • **2026 年 10 月 20 日：**PHP 安全团队宣布将在 2026 年 10 月 21 日 14:00 UTC 发布安全版本，修复两个 CVSS v4.0 评分 9.2 的严重漏洞（php.net）。
  • **2026 年 10 月 21 日 03:02 UTC：**Cloudflare 为其客户（包括免费套餐）开启了针对该攻击的防火墙规则。Cloudflare 称，细节在正式发布前就已泄露，并且它看到了针对其客户的攻击流量（Cloudflare 博客）。
  • **2026 年 10 月 21 日：**PHP 发布了修复版本和两份安全公告，GHSA-w8hw-w9fx-j79w 和 GHSA-6wmf-4rv5-p3rp，两者均为严重级别，评分 9.2。

这两个漏洞被称为 “php2shell”（Cloudflare 博客、BleepingComputer）。英国国家网络安全中心（NCSC）要求各组织更新，如果系统无法尽快更新或缓解，则考虑将其下线（NCSC）。

谁受影响

据 PHP 称，所有处理网页请求的 PHP 安装都有风险，包括 PHP-FPM、Apache 的 mod_php、php-cgi、FrankenPHP 和 LiteSpeed。PHP 认为 mod_php 的风险最高：已演示的利用只需一个无需认证的请求，在任何应用代码运行之前即可成功（php.net）。

两份公告都把低于 8.2.35、8.3.36、8.4.27 和 8.5.12 的所有版本列为受影响版本（GHSA-w8hw-w9fx-j79w、GHSA-6wmf-4rv5-p3rp）。更老的分支同样受影响：NCSC 称从 PHP 5 起（NCSC），Cloudflare 称 PHP 5.4 及以上（Cloudflare 博客）。

如果你的网站使用 PHP，并且自 10 月 21 日下午起没有人更新过 PHP，请假定它受到影响。

如何查看网站使用的 PHP 版本

**在 WordPress 中：**进入 工具 > 站点健康 > 信息，打开 服务器 部分。那里会显示你的网站运行的 PHP 版本（WordPress.org 文档）。如果站点健康还提示你的网站运行的是过时的 PHP 版本，请当作紧急情况处理。

**在主机控制面板中：**大多数面板（cPanel、Plesk、DirectAdmin 以及主机商自己的面板）都有查看或选择 PHP 版本的页面，常见名称是 “PHP 版本”、“PHP 选择器” 或 “PHP 设置”。找不到的话，请询问主机商。

把你看到的版本与下面的修复版本对照。有一点要注意：Linux 发行版和长期支持（LTS）供应商提前拿到了补丁，并发布自己的软件包（php.net）。即使已包含修复，它们的版本号也可能与 PHP 项目的版本号不一致。如果你的主机商使用发行版的软件包，可靠的答案要由主机商给出，不能只看版本号。

现在该做什么

1. 升级到已修复的版本

你的 PHP 分支 修复版本 支持状态
8.5 8.5.12 安全修复持续到 2029 年 12 月 31 日
8.4 8.4.27 安全修复持续到 2028 年 12 月 31 日
8.3 8.3.36 安全修复持续到 2027 年 12 月 31 日
8.2 8.2.35 安全修复持续到 2026 年 12 月 31 日，之后停止支持
8.1 及更早 没有官方发布 已停止支持，见下文

修复版本来源：php.net。支持日期来源：PHP 受支持的版本。

如果你用的是 PHP 8.2，请现在更新到 8.2.35，并计划升级到 8.3 或更新版本。PHP 8.2 在 2026 年 12 月 31 日之后不再获得安全修复（php.net）。

2. 如果你用的是 PHP 8.1、8.0、7.4 或更早版本

PHP 项目不再为 PHP 8.1 及更早版本发布更新。一些发行版和 LTS 供应商提供了回移植的修复。鉴于漏洞的严重程度，PHP 安全团队还为 PHP 7.4、8.0 和 8.1 发布了最小化的源码回移植补丁，面向从源码编译 PHP 或没有 LTS 供应商的用户（php.net）。

对于使用共享主机或托管主机的普通企业网站，办法更简单：在主机控制面板里切换到受支持的版本（8.3 或更新），或者请主机商代为切换。切换后要测试网站，因为旧的插件和主题有时在新版 PHP 上会出问题。

3. 询问你的主机商

给主机商发一条简短的消息：

您好，我账户上的 PHP（域名：example.com）是否已经修复了 CVE-2026-109618 和 CVE-2026-109619？我现在用的具体是哪个 PHP 版本或软件包？如果还没更新，什么时候会更新？

如果你自己管理服务器，并且使用由志愿者维护的 rpms.remirepo.net 软件源，PHP 称该源在 10 月 21 日不会有更新，并建议改用发行版的软件包或从源码编译（php.net）。

4. 防火墙只能争取几天，不是修复

Cloudflare 在所有带 WAF 的套餐（包括免费套餐）上部署了针对已知攻击方法的规则（Cloudflare 博客）。Cloudflare 的首席技术官称这些规则只是权宜之计，并要求管理员打补丁（Tenable）。PHP 自己表示没有完整的缓解措施，更新是唯一安全的选择（php.net）。

有两点限制。规则只覆盖已知的攻击模式，而攻击者已经在修改载荷来绕过它们（Cloudflare 博客）。另外，如果攻击者可以直接通过 IP 地址访问你的服务器，这些规则就起不到任何保护作用，所以源站服务器应当只接受来自 Cloudflare 的网页流量（Sansec）。

5. 如果今天无法更新

PHP 列出了一些配置修改，可以减少已知攻击路径的暴露，但不能让服务器变得安全（php.net）。它们是服务器设置，所以在共享主机上必须由主机商来应用。请把下面这份清单交给你的开发人员或主机商：

  • 针对 CVE-2026-109618：以应用无法覆盖的方式设置 memory_limit=-1（例如在 FPM 池或 Apache 配置中使用 php_admin_value），设置较低的 post_max_size（不上传文件时 8M，上传文件时 32M），并让 upload_max_filesize 低于它，同时在 Web 服务器或代理层限制请求大小、字段数量、multipart 分段数和请求头数量。不要使用 RLIMIT_AS 或 RLIMIT_DATA。
  • 针对 CVE-2026-109619：在 php.ini、FPM 池或服务器配置中设置 session.upload_progress.enabled=0，并重启所有 worker（ini_set() 和 .user.ini 对此无效）。在 PHP 8.5 上，还要设置 fatal_error_backtraces=0 并重启所有 worker。移除会产生警告的无效或已弃用的按请求设置。

技术细节

两个漏洞来自同一类问题：当请求异常结束时，PHP 可能把内存留在损坏的状态，而后续步骤信任了这块内存（BleepingComputer、Cloudflare 博客）。

CVE-2026-109618，通过 OOM 破坏实现 RCE（GHSA-w8hw-w9fx-j79w）。PHP 在内存耗尽时用 longjmp() 中止请求。在某些位置，请求内存在完全初始化之前就可以被访问。如果此时任何一次分配失败，请求关闭阶段就可能读取到只构建了一半的数据。攻击者可以用 multipart 请求强制触发内存不足：没有可用内容长度的请求体、带有大量请求头的分段，或带有嵌套名称的大量空文件字段。在 Apache mod_php 下，这发生在自动解析请求体的过程中，早于任何应用代码运行。在默认输入限制和内存限制下，已确认可对 mod_php 以 Web worker 账户的身份实现远程代码执行。根据源码分析，FPM 被评估为易受攻击，但尚未演示完整的 FPM 利用。补丁把内存不足时的 longjmp() 替换为在安全点延迟执行的软停止，以及在更高阈值触发的强制 _exit()。

CVE-2026-109619，通过过期全局状态实现 RCE（GHSA-6wmf-4rv5-p3rp）。PHP worker 保存着一些全局状态（错误、会话、对象和扩展状态），这些状态指向由某个请求拥有的内存。致命错误（包括内存耗尽或 Maximum execution time exceeded）可能跳过对这些状态的重置。同一个 worker 处理的下一个请求，就可能在正常初始化之前使用已释放的内存，这就是释放后使用（use after free）。已确认两个早期使用者：在初始化之前应用的按请求 INI 设置所产生的警告，以及会话上传进度，后者默认开启，且不需要应用调用 session_start()。PHP 8.5 的 fatal_error_backtraces 路径是已确认的 mod_php 利用的基础。会话路径已在 mod_php 和 FPM 上都得到验证。用 error_reporting、display_errors 或 @ 隐藏错误并不能起到保护作用。

两份公告的评分都是 9.2，向量为 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：网络攻击、无需权限、无需用户交互、攻击复杂度高，对服务器的机密性、完整性和可用性造成全面影响。

ShieldWave 检查什么

从外部看，没有人能判断一台服务器是否已打补丁。扫描能看到的，是服务器自己声明的 PHP 版本。

  • shieldwave.io 的免费扫描会读取 X-Powered-By 响应头。如果服务器报告的 PHP 版本低于其分支的修复版本，或者所在分支根本没有修复，报告就会列出一条 php2shell 发现，包含两个 CVE 编号以及你需要的版本。许多主机商会隐藏这个响应头，发行版打补丁时也不会改版本号，所以出现发现意味着 “去问你的主机商”，而没有发现并不能证明服务器已打补丁。
  • WordPress 的 Ensomedia Security 插件会显示网站运行的 PHP 版本，以及该分支是否仍受支持（插件页面）。这能抓住此次事件中最糟的情况：网站运行在 PHP 8.1、8.0、7.4 或更早版本上，得不到任何官方修复。插件免费，无需账户，收录在 WordPress.org 插件目录中。在后台依次进入 插件 > 安装插件，搜索 “Ensomedia Security”。

要确认确切的补丁级别，请使用站点健康和上面的表格，并向主机商确认。

来源

官方来源：

其他来源：