我的 WordPress 又被打了：一次 7.0 漏洞入侵与修复复盘

前几天，我的 WordPress 又被打了。

一开始看到的现象还算“常规”：后台多了几个完全不认识的管理员，插件列表里出现了文件管理器和能执行代码的可疑插件。于是我删掉恶意账号、卸载插件，顺手检查了一遍页面，以为事情到这里就结束了。

结果只隔了一天，对方又回来了。这次不但重新注册了更多管理员，还把网站标题改成了广告。到这里基本可以确定：之前做的只是清理表面症状，真正的入口一直没有被堵住。

先说结论

这次入侵的根因是 WordPress 7.0 中的两个安全漏洞：CVE-2026-63030 和 CVE-2026-60137。受影响的是低于 7.0.2 的 WordPress 7.0.x 版本，而我的网站当时正好运行在 7.0。

从访问日志、数据库记录和文件时间线还原出的攻击链大致如下：

1. 攻击者利用未认证的 REST Batch 请求创建管理员账号；
2. 使用新管理员账号登录后台；
3. 通过后台上传带有 WebShell 或文件管理能力的插件；
4. 继续创建账号、修改站点信息，并留下持久化入口。

这也解释了为什么单纯删除插件没有用：只要漏洞还在，攻击者随时可以再创建一个新的管理员，然后把同样的东西重新上传回来。

这次没有急着“删干净”

真正开始修复之前，我先停下了清理动作。因为删除恶意文件、账号和日志虽然看起来痛快，却也可能把最有价值的调查线索一起删掉。

这次先保全了几类材料：

• 网站目录的完整副本、逐文件元数据和 SHA-256；
• 数据库逻辑备份与后续物理备份；
• Web 服务、应用、运行环境和网络入口日志；
• 容器镜像、运行状态、网络配置和关键服务信息；
• 修复前后的配置副本与校验清单。

原来的受感染站点也没有直接覆盖，而是整体移到隔离目录。后续所有分析都基于副本完成，真正恢复上线时则使用可信来源重新构建。

为什么选择干净重建

一个已经允许攻击者上传并执行 PHP 的 WordPress，不能再简单地把“看起来可疑”的几个文件删掉就继续使用。你无法证明没有漏掉一个藏在主题、插件、uploads、缓存目录甚至核心文件里的后门。

所以这次的恢复策略是：

1. 使用官方已修复版本的中文包重建核心；
2. 对全部官方核心文件执行校验；
3. 主题和插件只从官方仓库或可信上游重新下载；
4. 不复用受感染目录里的任何可执行文件；
5. 清理恶意用户、附件、草稿和会话数据；
6. 轮换管理员密码、数据库密码和 WordPress Salt。

最终官方核心文件校验全部通过，管理员也恢复到原来的一个，用户注册被关闭，所有旧会话和应用密码全部失效。

仅仅升级版本还不够

补上漏洞只是第一层。为了降低以后某个插件再次出现漏洞时的破坏范围，我又补了几层限制。

• 关闭后台文件编辑、插件安装和主题安装；
• 让 PHP worker 无法写入 WordPress 核心和插件目录；
• 禁用业务不需要的进程执行和外部命令相关函数；
• 在 Web 服务器层直接拒绝 uploads 目录里的可执行脚本请求；
• 保留 uploads 的正常图片上传能力，但不允许它成为代码执行目录；
• 重新检查所有已知 WebShell 地址，确认它们均返回 404。

Web 服务器规则上线时还专门放置了一个短暂的无害脚本探针：如果请求到达脚本解释器，它会产生可区分的响应；如果规则生效，则必须直接返回 404。测试完成后探针立即删除。这样验证的不是“配置看起来对”，而是实际请求确实无法执行。

修完安全问题，又踩了一个 DNS 坑

网站恢复后，站点邮件插件又无法发信。最初以为是外部 SMTP 服务的账号或 TLS 配置有问题，最后发现是容器 DNS：内置 DNS 对一个不存在的 AAAA 记录处理异常，容器里的系统解析器因此把整个域名解析判定为失败。

为容器网络指定明确的 IPv4 上游 DNS 后，域名解析、587 端口、STARTTLS、证书验证和实际测试邮件才全部恢复正常。这也提醒我，故障发生在“发邮件”这个动作上，不代表问题一定在邮件账号本身；还是得分层验证 DNS、TCP、TLS、认证和投递。

我从这次事件里记住的几件事

1. 删除后门不等于修复入口。 如果不知道攻击者怎么进来的，他大概率还会回来。
2. 先保全证据，再动手清理。 文件时间、日志、数据库记录和哈希往往比后门文件本身更有价值。
3. 核心、主题和插件尽量干净重建。 不要试图靠肉眼证明一个被完全控制过的目录已经安全。
4. 后台管理员权限必须视为代码执行权限。 能装插件，通常就等于能执行 PHP。
5. uploads 应该能写，但绝不能执行。 这条边界值得在 Web 服务器或其他网关层单独落实。
6. 修复要有可验证的成功标准。 版本号、文件校验、真实请求、日志和服务状态都要检查，而不是“页面能打开就算好了”。

这次最直接的教训还是那句老话：备份不是有一个压缩包就够了，安全也不是删掉几个可疑文件就结束了。

后续打算怎么维护

以后会定期检查管理员账号、插件变化、uploads 可执行文件、核心文件校验和访问日志；更新前先备份，更新后验证首页、登录、数据库和邮件。后台安装插件的能力会继续保持关闭，需要更新时只在维护窗口从可信来源手动部署。

至于攻击者是谁，目前只能追到多个代理或攻击节点，还不足以确认真实身份。不过对网站维护来说，最重要的不是和某个 IP 猫鼠游戏，而是把入口封住、缩小权限、保留证据，并确保下一次异常出现时能更快发现。

如果你也在使用 WordPress 7.0.x，至少先确认自己已经升级到修复版本，并认真检查后台管理员和插件列表。不要等到网站标题变成广告，才发现“昨天删掉的东西今天又回来了”。