PHP2Shell 漏洞应急指南：WordPress 站长该做什么、怎么查、怎么修（2026）

三句话结论：2026 年 10 月 21 日，PHP 官方紧急修复了两个代号「PHP2Shell」的严重漏洞——它们藏在 PHP 语言引擎本身，攻击者发一个恶意 HTTP 请求就能在你的服务器上执行代码，不需要登录、不需要你的网站有任何插件漏洞；官方修复版已于 10 月 21 日发布，你的修复动作通常只需要 10 分钟；如果你的 PHP 版本没人管（尤其是还在跑 PHP 8.1 或更老版本），这事今天就该办。

这篇文章按「查版本 → 对照修复表 → 按场景修复 → 验证 → 事后排查」的顺序给你完整流程。写这篇文章时，一位朋友公司的 WordPress 服务器（Ubuntu 22.04 + nginx + PHP 8.1）刚刚在我们协助下完成这套修复，全程记录在文内，你可以直接照做。

先搞清楚：这次漏洞为什么值得你立刻动手

两个漏洞编号是 CVE-2026-109618 和 CVE-2026-109619，CVSS v4.0 评分均为 9.2（严重）。和以往「某个插件出洞、升级插件就行」的事故不同，这次的问题出在 PHP 解释器最底层的内存管理上：

• CVE-2026-109618（内存耗尽路径）：PHP 在处理超大请求触发内存上限时，可能在内部数据还没初始化完就被中断，清理阶段把无效数据当有效数据用，造成内存破坏乃至代码执行。已确认的触发入口是 multipart/form-data 请求——就是浏览器上传文件用的那种格式，WordPress 的评论、媒体上传都在用它。
• CVE-2026-109619（状态残留路径）：一个请求发生致命错误后，worker 进程里残留了指向已释放内存的状态；下一个请求复用这个 worker 时就会踩进失效内存。已确认的入口之一是 session.upload_progress——这个功能在 PHP 里默认是开着的。

安全公司 Wiz 已经用这套漏洞对最新版的 WordPress（连插件都不用装）演示了完整的未认证代码执行，还能直接读出 PHP 进程内存里的数据库密码和 API 密钥。Cloudflare 在官方补丁发布前就观测到了攻击流量，补丁发布数小时内攻击尝试从数千次飙升到数百万次。这不是「可以等等看」的漏洞。

还有一点很多教程没讲清楚：漏洞在 PHP 引擎里，所以升级 WordPress 本体、换安全插件、改后台密码，统统没用。唯一的完整修复是升级服务器上的 PHP 本身，升级完还要重启 PHP 服务。

第一步：查你的 PHP 版本（3 分钟，三种方法任选）

修复的前提是知道自己在跑什么版本。三种方法按方便程度排序：

方法一：WordPress 后台（最简单，人人可用）
登录 wp-admin → 左侧「工具」→「站点健康」→「信息」标签 → 展开「服务器」一项，「PHP 版本」就写在里面。

方法二：命令行（有 SSH 权限的）

php -v

或者看真正在跑 web 请求的 PHP-FPM 版本（比 CLI 更准，有些服务器 CLI 和 FPM 版本不同）：

ps aux | grep php-fpm
# 输出里 master process 指向的路径会带版本号，例如 /etc/php/8.1/fpm/php-fpm.conf

方法三：宝塔面板
登录面板 →「软件商店」→「已安装」→ 找到 PHP，版本号直接显示在名称里。

第二步：对照修复版本表

PHP 官方 2026-10-21 发布的修复版本如下（含修复的最低版本，等于或高于它就安全）：

关键提醒：如果你的版本低于对应修复版，或者你在跑 8.1/8.0/7.4——都算受影响范围，往下走第三步。查出来已经是修复版或更高？也建议把第六步的事后排查过一遍，因为补丁发布前攻击流量已经存在。

第三步：按你的场景修复

场景 A：虚拟主机 / 托管主机（SiteGround、Bluehost、cPanel 空间等）

PHP 由服务商管理，你自己动不了——立即给服务商发工单，就问一句：「你们的 PHP 是否已更新到包含 CVE-2026-109618 和 CVE-2026-109619 修复的版本？我的站点跑的是哪个版本？」正规服务商 10 月 21 日前后就应完成（主流面板 cPanel/Plesk 的上游同步很快），回复含糊或拖延的，把「迁移」提上日程。

场景 B：宝塔面板（国内用户最多）

宝塔官方 10 月 21 日已发公告，修复覆盖得很全：PHP 8.2–8.5 同步了官方修复版，7.4/8.0/8.1 也打包了编译补丁版（这三个 EOL 版本宝塔自己编了修复）。操作路径：

1. 登录宝塔面板 →「软件商店」→「已安装」
2. 先点右上角「更新软件列表」（不刷新列表看不到新版本）
3. 找到网站正在用的 PHP 版本 → 点「更新」→ 按提示升级到含修复的版本
4. 如果装了多个 PHP 版本，逐个检查，别漏掉还在服役的旧版本
5. 升级完成后重启对应 PHP 服务（面板会在更新时处理，确认一下状态是「运行中」即可）

宝塔的从零建站流程见这篇宝塔面板搭建 WordPress 教程；顺手说一句，宝塔公告里同样建议 8.1 及更早版本的用户尽早规划迁移到受支持分支——补丁只是这次的应急，下个漏洞 EOL 版本就没有人管了。

场景 C：Ubuntu / Debian VPS，apt 安装的 PHP（文中案例的实际情况）

PHP 8.1 虽然官方 EOL，但 Ubuntu 22.04 LTS（jammy）在标准安全维护期内，Canonical 已把修复 backport 进仓库（安全通告 USN-8948-1/-2，修复版本 8.1.2-1ubuntu2.28）。也就是说 8.1 用户在 Ubuntu 22.04 上不需要升级大版本，小版本补丁即可：

# 刷新索引
apt-get update

# 升级已安装的 php8.1 包（按你的实际版本号替换 8.1）
apt-get install -y --only-upgrade php8.1-bcmath php8.1-cli php8.1-common \
  php8.1-curl php8.1-fpm php8.1-gd php8.1-mbstring php8.1-mysql \
  php8.1-opcache php8.1-readline php8.1-xml php8.1-zip

# 重启 FPM 加载新二进制（关键步骤，不重启等于没修）
systemctl restart php8.1-fpm

如果你开着的自动安全更新（unattended-upgrades），补丁通常会在官方发布后一两天内自动装上——但主动升级永远比等更稳，尤其这种在野利用的漏洞。

一个坑要避开：用 Remi 仓库（rpms.remirepo.net）的 CentOS/RHEL 用户注意，官方修复发布当天 Remi 并没有同步更新，建议先切发行版源或盯紧 Remi 的后续版本再升级。

场景 D：Docker / 容器

容器里的 PHP 不会随宿主机补丁自动更新。用官方镜像（php:8.x-fpm 等）的，拉取修复后的新镜像重新构建、滚动发布，并确认旧容器已退出；用的旧标签（8.1 及以下）官方镜像不会给修复，换镜像源或换版本。

场景 E：顺手换个思路——自己买台 VPS 自己管

这次事件暴露出托管用户最大的软肋：补丁节奏完全看服务商脸色。如果你愿意每周花 10 分钟管自己的服务器，一台入门 VPS 就能把 PHP 版本、更新节奏全部握在自己手里。按小时计费、机房多的 Vultr 适合先开一台练手，用完销毁只花几块钱；长期跑站可以看它的深度测评再决定。到手先把5 个安全配置做一遍，再装网站。

第四步：重启之后，怎么确认真的修好了

升级 ≠ 修复，三个检查一个都不能省：

1. 版本号确认：php -v 或宝塔面板里看到的是修复版本（8.2.35+ / 8.3.36+ / 8.4.27+ / 8.5.12+，或发行版 backport 版本）。
2. 补丁内容确认（发行版用户）：运行 apt changelog php8.1-common（按你的分支替换包名），在输出里检索 CVE-2026-109618——搜得到就是官方确认包含修复。
3. 进程加载确认：systemctl status php8.1-fpm（或对应服务）的启动时间必须晚于软件包安装时间——补丁装完不重启进程，跑着的还是旧二进制。

最后访问一遍网站首页、文章页和后台登录页，确认业务正常。案例服务器修复当天的完整记录：12 个 php8.1 包升级到 2.28 + 重启 FPM，全程中断不到 1 秒，首页、REST 接口、文章页、登录页外部访问全部 200。

第五步：暂时升不了的，上临时缓解（不能替代补丁）

如果因为业务原因短期内升不了，下面几招能挡住已公开的主要攻击路径——但注意 PHP 官方和各家安全公司都强调：缓解只覆盖部分路径，不是修复，能升赶紧升。

缓解 1：关闭 session 上传进度（最优先，1 分钟）

这个功能默认开启、是已确认的攻击入口之一，绝大多数 WordPress 站用不到它。写入 php.ini（或宝塔的「PHP 设置 → 配置修改」），不要用 .user.ini 或代码里的 ini_set（太晚生效，没用），改完重启 PHP：

session.upload_progress.enabled = 0

缓解 2：Web 服务器层拒绝 multipart 请求（有取舍）

已公开的利用都走 multipart/form-data。nginx 用户可在 server 块加：

if ($http_content_type ~* "multipart/form-data") { return 403; }

代价是 WordPress 的媒体上传、部分主题/插件的表单会失效——适合纯内容展示站临时应急，用完记得删。更精细的做法是只对非上传接口拒绝、放行媒体上传端点。

缓解 3：套上 Cloudflare（免费版已默认生效）

Cloudflare 在官方披露前 9 小时就部署了针对性 WAF 规则，免费套餐自动生效、无需任何操作（Managed Free Ruleset）。注意两点：规则只保护走 Cloudflare 代理的流量，攻击者直连你源站 IP 就绕过了；官方 CTO 明确说这只是「止血」。如果你的站还没套 CDN，配置方法见Cloudflare 免费套餐指南。

缓解 4：实在不行就临时下线

荷兰多家政府网站在补丁发布前直接选择关站等补丁——这不是笑话，对高价值站点来说，停机几小时远比被入侵划算。注意 WordPress 自带的「维护模式」没用：PHP 在应用代码运行之前就可能被攻击。真要下线，直接停 PHP-FPM 服务、让 nginx 返回静态页。

第六步：事后排查——补丁发布前的 24 小时你有没有中招

补丁发布前 exploit 细节已经泄露、攻击已在进行。如果你的服务器当时对公网开放且未修复，花 10 分钟过一遍这份清单：

• PHP-FPM 日志：最近几天有没有大量 worker 崩溃重启（journalctl -u php8.1-fpm --since '7 days ago'），异常崩溃是利用尝试的典型痕迹
• 上传/临时/会话目录：有没有不明来历的 .php 文件
• 持久化后门：crontab -l、/etc/cron.*、systemd 新增服务、~/.ssh/authorized_keys、/etc/passwd 有没有陌生条目和用户
• 进程外联：php-fpm 子进程有没有异常的网络连接
• 密钥轮换：凡是 10 月 20 日之后到重启完成之前对公网开放的服务器，建议轮换数据库密码、应用密钥和 API 密钥——Wiz 已证明攻击者即便不执行代码也能读取进程内存中的机密

发现任何一条中招迹象，别自己硬扛，先断网取证。日常加固的水平线可以参考这篇VPS 到手后的 5 个安全配置。

长期建议：别再让服务器跑 EOL 的 PHP

这次事故里最惨的群体就是 PHP 8.1 及更早版本的用户——官方不发布修复版，只能等发行版或面板商施舍 backport，时间窗完全被动。把这张表记在心里：

WordPress 6.x 对 PHP 8.3/8.4 的兼容性已经很成熟，主流插件基本都跟上了。升级前先在测试环境过一遍，重点检查老插件；升级后用跑分方法对比一下性能，PHP 每升一代都有免费的性能红利。

FAQ

Q：我的 WordPress 和插件都是最新的，还有事吗？

有。这次漏洞在 PHP 引擎里，与 WordPress、插件、主题的版本完全无关——Wiz 的演示对象就是最新版 WordPress。唯一判断标准是你服务器上的 PHP 版本。

Q：我用的虚拟主机，服务商说「已处理」就算完了吗？

让他们给具体版本号。回复「已修复」但不肯说 PHP 版本的，用站点健康里的「服务器」信息自己核对：看到 8.2.35 / 8.3.36 / 8.4.27 / 8.5.12 或更新，才是真的修了。

Q：装了 Cloudflare 就不用升级了吧？

不行。WAF 规则挡的是「已知的攻击姿势」，攻击者换姿势或直连源站 IP 就绕过了，Cloudflare 自己都说这是 STOPGAP（临时止血）。正确姿势是：WAF 保持开着，PHP 照常升级。

Q：PHP 8.1 的 backport 补丁可靠吗？以后怎么办？

可靠。Ubuntu 的 backport 由 Canonical 安全团队维护，和官方修复覆盖相同 CVE，质量有保障——文中案例就是用 8.1.2-1ubuntu2.28 修复的。但 backport 只覆盖「本次漏洞」，8.1 后续再出新洞依然只能靠发行版跟进，长期还是建议迁到 8.3+。

Q：怎么第一时间知道这类漏洞？

三个免费渠道：PHP 官方公告页（php.net 的 releases）、Ubuntu 安全通告（usn.ubuntu.com，apt 用户订阅）、以及如果你套了 Cloudflare，它的 blog 会在大事件时同步防御动作。对 WordPress 站长来说，确认你的服务器开着 unattended-upgrades 自动安全更新，是最省心的一道保险。