遇到 WordPress 高危漏洞周，正确顺序不是等自动更新，而是先确认 Cloudflare WAF 护住流量，再确认版本和后台内容链路。
- 01先读摘要，判断是否与你的场景相关。
- 02再看来源，保留继续查证的路径。
- 03最后看步骤、风险和可复用动作。
WordPress 7.0.2 这次不是普通维护版。WordPress 官方在 2026 年 7 月 17 日直接把它定性为安全发布，修复一个 critical 和一个 high 严重级别问题，还对受影响版本开启了强制自动更新。同一天，Cloudflare 也公开说明它已经为两类漏洞下发了 WAF 规则。对内容站和客户站来说，这类“补丁周”最怕的不是没有修，而是你以为自动更新会全搞定，结果代理层、插件兼容、对象缓存和规则覆盖根本没核实。
适用场景
这篇清单适合有公开访问流量的 WordPress 站点，尤其是挂在 Cloudflare 代理后面的内容站、客户站、会员站和小团队维护站。你如果负责多个站点，也很适合把这篇文章当成“当天应急流程”：先确认 Cloudflare WAF 护住流量，再确认 WordPress 版本已到安全分支，再跑一轮回归。
不适用场景
如果你的站点没有通过 Cloudflare 代理，或者本来就不在 6.8、6.9、7.0 这些受影响分支，这篇文章里的 WAF 部分价值会下降。另外，如果你做的是自托管开发环境、无公网流量、不会接收外部请求的临时测试站，也没必要照着做全部步骤。那种环境更应该先升级，再看兼容性，而不是把精力都放在边缘层规则上。
先搞清这次风险边界
WordPress 7.0.2 官方公告写得很重：这是 security release，建议立即更新；7.0.2 修复一个 critical 和一个 high 问题；6.9.5、6.8.6 和 7.1 beta2 也同步提供对应修复。Cloudflare 的文章则补上了运维视角：它为两类漏洞下发了新规则，覆盖一条 SQL injection 以及一条和 REST API batch endpoint 相关、可导致未认证远程代码执行的链路；Cloudflare 表示规则已部署到所有代理经过 WAF 的客户，包括 free 和 paid plans，不过它也强调 WAF 只是降低暴露面，不是补丁替代品。
这两份官方信息合起来的结论很简单：今天的正确动作顺序不是“等自动更新自己跑完”，而是“先确认 WAF、再确认版本、再做回归”。
准备材料
- Cloudflare 仪表盘权限，至少能看 WAF Managed Rules 和 Security Events。
- WordPress 管理员权限，能检查核心版本、插件和缓存状态。
- 站点清单，标出每个站当前跑的是 6.8、6.9 还是 7.0 分支。
- 一份最小回归清单：首页、文章页、搜索、表单、登录、编辑器、媒体上传。
- 一个缓存清理路径：Cloudflare cache、WordPress object cache、页面缓存至少要知道怎么刷。
步骤一：先确认站点是否真的在受影响范围内
不要把所有站一锅端。先按分支分组：
- 跑 7.0 的站，目标版本是 7.0.2。
- 跑 6.9 的站，目标版本是 6.9.5。
- 跑 6.8 的站，目标版本是 6.8.6。
- 低于 6.8 的旧站，根据 WordPress 公告并不在这次受影响范围，但如果站点长期无人维护，也不能因此忽略整体升级风险。
做这一步的目的，是避免你在沟通里只说“升级到 7.0.2”，结果某些老站其实应该走 6.9.5 或 6.8.6 分支。多站点维护时，这种口径错误很常见。
步骤二：在 Cloudflare 侧确认规则已经生效
Cloudflare 文章里给了一个非常有用的差异点：Pro、Business、Enterprise 用户应确认 Cloudflare Managed Rules 已启用；Free plan 用户则由 Free Ruleset 自动保护。操作上建议这样做：
- 打开站点对应的 Cloudflare dashboard。
- 进入 WAF / Managed Rules。
- 如果你是 Pro 及以上，确认 Cloudflare Managed Rules 处于启用状态。
- 检查有没有组织级或站点级 override 把规则动作从 Block 改成了 Log。
- 到 Security Events 里搜当天和 WordPress 相关的拦截事件，确认规则不是“理论上已启用，实际上被覆盖”。
Cloudflare 这次特别提醒过：很多站点会因为自定义 override 把整个规则集的默认动作改掉。你如果只看到“Managed Rules is enabled”就收工，最关键的误配点反而漏掉了。
步骤三：马上确认 WordPress 是否已经升到安全版本
WAF 护得再好，也不能替代补丁。WordPress 官方已经说明，对于受影响版本，会通过 auto-update system 推强制更新。但强制更新不等于你可以不检查。建议按这个顺序做：
- 在 Dashboard > Updates 里确认核心版本号。
- 如果没到安全版本，立刻手动更新。
- 多站点环境里，用统一清单记录每个站当前版本和更新时间。
- 检查是否有 staging 或遗忘子站仍停在旧版本。
这一步最容易出现的误判，是把“主站已自动更新”当成“整个账号下所有站都没问题”。尤其是客户站、临时子站、活动页子目录，往往最容易被忘记。
步骤四：把对象缓存、REST API 和登录路径列入重点回归
Cloudflare 的文章点名了 REST API batch endpoint 相关风险，WordPress 公告里也提到一条涉及 REST API batch-route confusion 和 SQL injection 的链路。对站长来说，回归时应该提高这几条路径的优先级：
- 登录和管理后台能否正常进入。
- 文章编辑器是否能保存、更新、预览。
- 媒体上传是否正常。
- 前台是否存在明显 403、500 或接口保存失败。
- 对象缓存开启的站，清缓存后再做一次编辑和读取验证。
别只看首页能开就算回归完成。安全版升级周最常见的问题，是后台编辑链路或缓存一致性出错，而不是首页直接挂掉。
步骤五：把“补丁前防护”和“补丁后验证”分成两张表
很多团队做应急时会把所有动作混成一串，然后第二天没人知道哪些已经完成。更稳的方式是拆两张表：
- 补丁前防护表：WAF 是否启用、规则动作是否为 Block、Security Events 是否有异常峰值。
- 补丁后验证表：核心版本、插件冲突、编辑器、媒体、缓存、前台页面、站点地图、关键表单。
这样做的好处是，如果半夜先做了 WAF 和版本更新，白天同事接班时能清楚知道哪些站还差回归，不会重复劳动，也不会漏掉真正该测的内容。
可直接复用的应急检查清单
- 确认站点分支属于 7.0 / 6.9 / 6.8 哪一类。
- 在 Cloudflare 检查 Managed Rules 或 Free Ruleset 保护状态。
- 检查是否有把 Block 覆盖成 Log 的 override。
- 确认 WordPress 已到 7.0.2、6.9.5 或 6.8.6。
- 回归后台登录、编辑器、媒体上传、前台文章页。
- 清理对象缓存和页面缓存后再测一次。
- 查看 Security Events，确认拦截规则正在生效。
- 把版本状态和验收结果记录到多站点台账。
实际例子：内容站在凌晨升级后的接班流程
假设你管理一个内容站，凌晨收到供应商通知说 WordPress 安全发布已自动更新。更稳的接班流程不是“首页没挂就行”，而是：
- 先在 Cloudflare 看 Managed Rules 是否启用，Security Events 是否出现相关拦截。
- 再在 WordPress 里核对版本是否真到了 7.0.2。
- 用编辑账号新建一篇测试草稿，检查保存与预览。
- 上传一张图片，确认媒体库和前台文章页都正常。
- 清一次缓存，再重开首页和最新文章页。
这五步跑完，你拿到的是“边缘层 + 核心版本 + 内容链路”三层都正常的证据，而不是只靠一张首页截图交差。
常见坑
- 以为 automatic update 一定覆盖所有站点和所有子环境。
- Managed Rules 已启用，但全局 override 把动作改成 Log，等于没真正拦。
- 只看前台，不测后台编辑和媒体上传。
- 没清对象缓存就做结论，结果读到的是旧状态。
- 把 WAF 当长期替代方案，补丁没跟上。
排错路径
- 版本没变：检查自动更新是否失败，再手动执行安全分支更新。
- WAF 显示启用但没拦截：先查规则 override，再查流量是否真的经过 Cloudflare 代理。
- 前台正常但后台报错：优先排查对象缓存、插件兼容和编辑器相关接口。
- 多站点里有一部分正常、一部分异常：重新按版本分支和代理状态拆组，不要假设所有站环境一致。
- 升级后图片或页面样式异常：清 WordPress、插件和 Cloudflare 三层缓存，再做第二轮回归。
后续维护建议
更新日期：2026-07-18。以后再遇到高优先级 WordPress 安全发布，建议固定采用“先确认 WAF、再确认版本、最后跑内容链路回归”的顺序。并且把多站点的版本分支、缓存方案、代理状态做成常驻台账。真正能缩短下次响应时间的，不是你今天记住了两个 CVE 编号，而是你把这次的应急路径沉淀成可重复执行的 SOP。