9 月 17 日 WordPress 7.1.1 发布，11 个安全修复里有一个点被很多人忽略：WordPress.org 从本月起对每一个插件更新强制跑 AI 安全扫描，高风险的直接拦在分发门外。对站长来说，这意味着「装插件」这件事的信任模型变了。这篇文章不只讲怎么升 7.1.1，更给你一份更新后真正该做的自查清单。
7.1.1 到底修了什么
11 个安全修复覆盖存储型 XSS、权限校验缺失、REST 模板控制器的路径穿越，以及一个被安全圈叫做 Click2Shell 的链：攻击者构造一个特制 URL，登录态的管理员点开就能静默安装并预览一个来自官方目录的非活跃主题，进而作为后续攻击的跳板。单独看每个漏洞都需要一定权限，但链起来就是「点一下链接 → 站点被控制」。
受影响的是 7.1.1 之前的所有版本。老分支（6.x / 7.0）有安全回溯补丁，但官方只主动支持最新版。结论很直接：能升就升。
更值得关注：插件上线前强制安全扫描
这次真正的行业变化在插件侧。WordPress.org 宣布，所有通过官方更新 API 发布的插件版本，现在都要先过一道自动安全审查——AI 模型配合 Jetpack Scan 打分，高风险直接自动拦截，开发者会拿到具体告警去修，而不是等事后人工申诉。
官方提到一个时间点：7 月 28 日那次扫描窗口曾拦下一个后门，当时它已经准备推送到约 2 万个站点。换句话说，以前「插件目录默认安全」是口号，现在是机制。
踩坑实录：我 9 月刚被插件漏洞攻破过
讲这个不是吓人，是我自己的真实经历。今年 9 月，站点上一个没及时更新的插件被曝出未授权文件上传漏洞（CVSS 9.8）。攻击者通过 REST 接口直接往 uploads 目录落盘了几百个脚本后门，清理时逐个枚举删除了六百多个文件。根因不是服务器被 SSH 攻破，就是「一个老版本插件 + 一个未授权端点」。
事后复盘最关键的一条：先堵入口再清理。我第一版脚本边删边被重新上传，因为漏洞端点还开着。正确顺序是先注销那个 REST 路由，再清后门，最后才升到修复版本。这次 WordPress 的强制扫描，本质就是把「发现后门」这件事前置到了分发环节。
更新后必做的 5 步自查清单
升级核心只是第一步。下面这份清单我建议更新完就照着过一遍：
确认真的变了
verify-checksums
逐个过更新
陌生账号/脚本
站外存 30 天
- 确认版本真的变了。后台「仪表盘 → 更新」看一眼，WP-CLI 跑
wp core version交叉验证——自动更新可能因权限失败，别信「已更新」的提示。 - 跑核心校验：
wp core verify-checksums。它把每个核心文件和官方版本比对，不匹配说明被人动过。 - 插件单独审。核心升了不等于插件安全。逐个看更新，删掉不用的；对新装插件先查作者在不在官方目录、最近是否通过安全扫描。
- 查异常痕迹。看有没有陌生管理员账号、uploads 里多出来的 .php、计划任务里不认识的 cron。
- 留一份能恢复的备份。数据库和文件都备，存在站点以外的位置，至少留 30 天。
| 环节 | 更新前（靠运气） | 更新后（靠机制） |
|---|---|---|
| 插件安全 | 目录默认信任 | 上线前强制扫描拦截 |
| 核心漏洞 | 手动跟进公告 | 7.1.1 已修 11 项 |
| 你的责任 | 出事再救火 | 升级后过 5 步清单 |
常见问题
Q：自动更新开着就不用担心了吧？
A：不一定。文件权限挡住自写、主机按自己节奏更新、核心文件被改过，都可能让自动更新漏掉。更新完还是要确认版本号。
Q：插件安全扫描会误杀正常插件吗？
A：高风险才拦，且给开发者具体告警去修，不是一刀切下架。对普通站长反而是利好。
Q：老版本不想升大版本怎么办？
A：装对应分支的安全回溯补丁（如 6.8.9 / 7.0.5），但官方只主动支持最新版，长期还是建议升。
你站点用的插件里，有没有那种「装了就再没管过」的？趁着这次机制上线，花十分钟过一遍清单，比出事后再清后门便宜得多。欢迎在评论区说说你排查时踩过的坑。
