PHP2Shell 是什么：两个 9.2 分漏洞，为什么这两天全网网站都在紧急更新
一句话结论：PHP2Shell 不是某个网站程序的漏洞，而是 PHP 语言核心本身爆出的两个远程代码执行漏洞（CVE-2026-109618 与 CVE-2026-109619），CVSS v4.0 评分均为 9.2 分，攻击者无需登录、无需任何用户交互就可能在服务器上执行代码。官方已在 2026 年 10 月 21 日紧急发布修复版本，升级到修复版本是唯一的完整修复办法。只要你的网站是用 PHP 做的，这两天就应该确认一遍版本。
这两天到底发生了什么？
时间线大致是这样的：
- 10 月 17 日：Amazon 的蜜罐系统在漏洞公开之前，就已经记录到针对这两个漏洞的利用尝试，说明在野利用先于公开披露出现；
- 10 月 20 日：漏洞细节提前泄露，留给网站运营者的缓冲时间被大幅压缩；
- 10 月 21 日：PHP 官方紧急发布修复版本（原定 10 月 22 日，因细节泄露提前了一天）；
- 公开后数小时内，网上已出现概念验证代码和大规模扫描，Cloudflare 表示已侦测到早期攻击；欧洲多国政府网站预防性下线了部分服务，FBI/NSA、CERT-EU、澳大利亚 ACSC 等机构均发布了紧急通告。
这两个漏洞由安全公司 Calif、Wiz 等在 AI 模型协助下发现，据披露已经在 PHP 代码中潜伏了约 14 年——这也是它影响面大的原因之一：受影响的不是某个新版本，而是多年来的存量安装。
两个漏洞分别是什么？
两个漏洞的类型相同（CWE-824：访问未初始化指针），但出问题的位置不同。用概念层的话讲清楚：
| 对比项 | CVE-2026-109618 | CVE-2026-109619 |
|---|---|---|
| 评分 | CVSS v4.0 9.2 分 | CVSS v4.0 9.2 分 |
| 触发场景 | 请求处理中内存耗尽（OOM），PHP 用 longjmp() 紧急中止请求时 | 请求处理中发生致命错误、被中止之后 |
| 问题本质 | 部分请求内存还没初始化完成，后续清理流程却把这块无效内存当作有效数据去读取和跳转 | 全局状态仍指向一块已在请求结束时被释放的内存，后续请求可能读到这块失效状态（释放后使用，use-after-free） |
| 共同点 | 都出在「请求异常中止后的收尾环节」；都不需要登录和用户交互；利用时攻击者需要用大量特制请求做堆内存布局、并命中同一个 worker 进程 | |
需要客观看待的一点是：触发崩溃类问题不难，但把利用做到稳定执行的门槛较高。不过「门槛较高」不等于可以拖——扫描和在野利用已经出现，拖得越久，被批量扫描命中的概率越高。
为什么影响面这么大？
按 W3Techs 的统计口径，全球约七成网站在服务端使用 PHP，WordPress 等主流建站程序都构建在 PHP 之上。而这两个漏洞影响的是所有处理 Web 请求的 PHP 安装方式，包括 PHP-FPM、Apache mod_php、php-cgi、FrankenPHP、LiteSpeed 等常见运行方式。也就是说，判断自己是否受影响的标准只有一个：服务器上的 PHP 版本，与你用什么程序建站无关。
网站运营者今天该做哪几件事？
- 先查版本：确认服务器当前 PHP 版本号，具体查法见常见问题栏目里的自查指南；
- 对照修复版本升级：8.5 → 8.5.12、8.4 → 8.4.27、8.3 → 8.3.36、8.2 → 8.2.35，低于对应修复版的都应尽快升级；
- 升级后重启 PHP 服务：不重启，新版本不会真正生效；
- PHP 8.1 及更早版本要特别处理：这些版本已停止官方支持、没有官方版本更新，官方只提供了 7.4 / 8.0 / 8.1 的最小源码补丁供自行编译者使用，部分 Linux 发行版会回移植修复——暂时无法升级的，应先把应用下线或与公网隔离；
- 不要指望改配置或 WAF 兜底：官方明确没有完整的配置缓解办法，WAF 和防火墙规则只能做临时缓冲；
- 分不清就问主机商：PHP 运行时通常由主机商或服务器管理员维护，更新 WordPress 和插件并不等于更新了 PHP。
网站安全没有旁观席。如果你的企业官网正运行在未修复的 PHP 版本上，先完成升级这一步；后续的日常巡检、版本跟进和内容运营，可以交给一套稳定的运营机制持续做，这也是我们一直在建站运营栏目里分享的方法。不确定自己网站情况的，可以通过本站联系我们页面的企业微信二维码咨询。
想用智盟CMS 为企业建一个能获客的官网？扫码咨询。
