F12笔记2026 年 10 月 21 日，PHP 官方要发一次紧急安全更新 —— 原因是两个被统称为 PHP2Shell 的远程代码执行漏洞。CVSS 评分 9.2，攻击者可以直接在服务器上执行任意代码、拿到 shell。这篇把「怎么判断自己有没有风险」「今晚该做什么」「有哪些常见误区」讲清楚。
一句话结论：只要你的服务器还在跑 PHP，今晚就该升级。
2026-10-21 22:15 更新：补丁已发布。Debian 13 的 stable-security 源已经推送 PHP 8.4.27（包版本 8.4.27-1~deb13u1）。本文作者所在服务器已用一条命令完成升级，并验证站点、后台、登录、PHP-FPM 全部正常 —— 实测记录见文末第 9 节。
1、漏洞基本信息
| 项目 | 内容 |
|---|---|
| 漏洞代号 | PHP2Shell |
| CVE 编号 | CVE-2026-109618 / CVE-2026-109619 |
| 危险等级 | CVSS 9.2（极度危险） |
| 漏洞类型 | 远程代码执行（RCE），可直接接管服务器 |
| 受影响版本 | PHP 5.4 及以上所有版本 |
| 补丁时间 | 北京时间 2026-10-21 22:00（14:00 UTC） |
| 补丁范围 | 只发布 PHP 8.2 / 8.3 / 8.4 / 8.5 的修复版本 |
披露方是安全公司 Sansec，另一家安全公司 watchTowr 已确认漏洞真实存在并可复现。受影响的不只是 WordPress，Magento、Shopware、WooCommerce 等电商系统和各类 CMS 都在范围内。
2、时间线：为什么今晚就要动手
按安全社区的说法，补丁发布后大约 15 分钟内就会出现针对全网的大规模自动化扫描 —— 也就是说，补丁发布的同时，攻击工具也准备好了。这不是「改天再说」的事情。
3、第一步：查自己的 PHP 版本
SSH 登录服务器，执行：
php -v看输出第一行的版本号：
- 8.2 / 8.3 / 8.4 / 8.5 → 今晚会有补丁，升级即可；
- 8.1 及以下（含 7.x、5.6） → 官方不会发补丁，只能尽快迁移到 8.2+。
如果你用的是面板（宝塔、1Panel 等），也可以在面板里看当前站点的 PHP 版本 —— 注意面板里可能装了多个版本，要逐个确认。
4、第二步：今晚升级并重启
补丁发布后（22:00 之后，Debian/Ubuntu 可能还要等官方源同步几小时），执行：
apt update
apt upgrade然后重启 PHP 和 Web 服务：
systemctl restart php8.4-fpm
systemctl reload nginx再确认一次版本：
php -v
php -r 'echo phpversion("Zend OPcache"), "n";'两个版本号都变新了，才算真的生效（OPcache 是独立的，不重启 fpm 它还会用旧代码）。
一个容易踩的坑：如果你用的是 Debian / Ubuntu 的官方源，补丁不一定会把版本号升到 8.4.27，而是打成 8.4.26-1~deb13u2 这种「回补版本」—— 版本号数字没变，但漏洞已经修了。所以不要死等某个版本号，看的是有没有新的软件包：
apt list --upgradable 2>/dev/null | grep -i php5、两个常见误区
误区一：改 php.ini 禁用 exec / system 就能防
不行。这个漏洞在 PHP 引擎层，利用过程不经过 disable_functions 里禁用的那些函数。改 php.ini、关掉 exec、shell_exec 之类的操作，对这类漏洞没有防护作用 —— 官方补丁之外，没有代码级的替代方案。
误区二：装个 WAF 插件就行
要分两种：
- 跑在 PHP 里的 WAF 插件（例如很多 WordPress 安全插件）—— 没用。它们本身就在被攻击的那个进程里执行；
- 网络层 WAF（Cloudflare、机房硬件 WAF）—— 有用，但只是止损。它能拦住已知的利用特征，让你不至于在补丁发布后的第一时间被打穿，但它不是修复。Cloudflare 已经为这次漏洞专门下发了规则，免费版同样覆盖（详见第 6 节）。
6、Cloudflare 免费版的 WAF 已经能挡（但要会确认）
2026-10-20，Cloudflare 官方专门发了一篇博文说明针对 php2shell 的防护：规则面向所有套餐下发，包括免费版。
具体位置是 Cloudflare Managed Free Ruleset（规则集 ID 77454fe2d30c4220b5701f6fdfb893ba），新增了 7 条规则：
Generic Rules - Anomalous Execution - 1 ~ 7 action = block我核对了自己站点的规则集：这 7 条规则都在、都是 block、并且都是启用状态（免费版，该规则集共 38 条规则）。也就是说 —— 如果你的站一直套在 Cloudflare 后面，也没有手动关掉托管规则，这层防护其实已经在生效了。
怎么确认自己的站有没有生效
- Cloudflare 后台 → Security → Settings → 找到 Cloudflare managed ruleset，确认写着 Always active（免费版默认就是开的）；
- 想看拦截记录：Security → Analytics 看托管规则的拦截数量，或 Security → Events 逐条查看；
- 如果之前为了排查问题手动关过托管规则，记得打开。
但别把 WAF 当补丁
Cloudflare 自己的 CTO 在说明里写得很直接：「This is a STOPGAP only.」—— 这只是临时缓解。原因很简单：
- WAF 是按已知的请求特征去拦的，而漏洞细节在公开前并不完整；
- 新的利用变种出现后，规则要跟着更新，中间存在时间差；
- 所以它降低的是「补丁发布后第一时间被打中」的概率，不能替代升级 PHP。
除 WAF 外，这两件事也建议做（和 WAF 无关，但能减少「即使被打穿」的损失）：
- 别让源站 IP 裸奔：如果站点套了 Cloudflare，在防火墙上只允许 Cloudflare 的 IP 段回源、其余直接返回 403 —— 攻击者必须先过 CF，WAF 才有机会拦；
- 备份：至少备份
/etc/php和数据库，升级出问题能快速回滚。
7、升级之后怎么验证
php -v/php-fpm -v版本已变新；systemctl is-active php*-fpm是 active；- 打开站点首页和一篇内页，确认返回正常；
- 登录 WordPress 后台，确认能正常登录、能发布文章；
- 如果站内开了页面缓存（WP Super Cache 等），可以顺手清一次，让新 PHP 生成的页面生效。
8、还值得注意的两点
- 8.1 及以下不会收到补丁，这不是「官方还在做」，是明确不做了 —— 这些版本只能迁移；
- 补丁发布后的一两天是最危险的窗口期，扫描量大、攻击自动化程度高。能今晚升就别拖到明天。
9、实测升级记录（2026-10-21 22:15）
- 检查：
apt list --upgradable | grep -i php→ 15 个php8.4-*包可升级，全部指向8.4.27-1~deb13u1； - 升级：
apt-get install --only-upgrade 'php8.4-*'，约 20 秒完成； - 重启：
systemctl restart php8.4-fpm && systemctl reload nginx； - 验证：
php -v→ 8.4.27；OPcache 8.4.27；首页、文章页、登录页全部200；PHP-FPM 的listen queue为 0。
整个过程站点中断时间不到 2 秒（只有 fpm 重启的那一下），nginx 全程正常响应。
另外一个实测结论：Debian 13 这次直接推的是 8.4.27 本体，不是前面提到的那种「版本号不变的回补包」。所以看到 8.4.27 出现就可以放心升级 —— 但升级前仍然建议先看一眼 apt list --upgradable 里具体是什么版本。
本文信息基于 2026-10-21 各安全厂商的公开披露（Sansec、watchTowr、php.net 安全公告及多家安全媒体），漏洞细节以官方公告为准。补丁发布后建议再核对一次版本号与官方说明。
