核心安全版一次修了二十多处，回溯补丁停在哪条分支
WordPress 核心安全版一次修了二十多处漏洞，回溯补丁停在哪条分支，比那更老的站点怎么办？这轮修复的下限停在 4.7.39，比 4.6 更老的分支拿不到任何补丁，只能靠站点自己处置。判断顺序是：先确认口径与分支覆盖，再看自动更新是否已经生效，最后为拿不到补丁的老版本安排隔离或迁移。
二十多处是按什么口径数的
公开统计给出的口径是这一轮修复覆盖二十二处漏洞、分布在十七条公告里，也就是「漏洞条目数」和「公告条数」两个口径，一条公告里可能包含多枚同类问题。引用这类数字时要写清按哪个口径，否则不同来源的数字看起来互相矛盾。
对运维来说口径差别并不影响动作：无论是按条目还是按公告，处置都是同一套——确认版本、确认分支、确认是否需要人工干预。
回溯补丁为什么有下限
WordPress 的支持策略只对少数活跃分支维护，本轮的回溯覆盖从当前主线一直到 4.7.39，跨了很多个版本系列；而 4.6 或更早的站点不在任何活跃分支上，官方直接不给补丁。这背后的约束是维护成本：老分支的代码结构差异大，逐个回合修复需要额外人力，项目宁可用支持周期把用户推到新版本上。
| 站点所处位置 | 能拿到什么 | 建议动作 |
|---|---|---|
| 当前主线版本 | 常规修复与安全补丁 | 开启后台自动更新，升级后核对权限 |
| 活跃分支的老版本 | 同日的回溯补丁 | 确认补丁版本号，安排窗口升级 |
| 低于分支下限 | 没有任何补丁 | 先隔离入口，再规划迁移到新分支 |
| 停用状态的站点 | 没有任何补丁 | 关闭公开写入面或直接下线 |
还在老分支的站点先做三件事
第一步是收窄暴露面：把登录入口、注册与表单、文件上传这类可写入的路径先限制起来，能关的先关。第二步是查已有入侵痕迹，重点看非常规目录里的可执行文件、被改过的模板与插件、以及突然多出来的管理员账号。第三步才是排升级或迁移：老分支没有补丁，意味着下一次公告仍然与你无关，长期停留在无补丁分支不是可接受的运维状态。
这三步的顺序不能倒：先做数据备份再动刀，否则一旦误判就把恢复选项也丢了。备份要覆盖数据与静态文件，且要真正恢复一次才算验收。
自动更新覆盖到哪一步
支持分支内的站点可以依赖后台更新拿到本轮补丁，未开启后台更新的站点要自己安排窗口。自动更新能覆盖核心补丁这一层，插件与主题往往仍需人工确认，尤其是在生产环境里担心兼容性问题的场景。自建系统的处理逻辑一样：AnQiCMS 在 v3.6.6 里同时修掉了列表排序参数注入与站点切换登录凭证可被伪造两条高危问题，这类升级公告给出的建议是升级后轮换站点签名配置并修改管理员口令，把可能被拿走的旧凭证一次性作废。
自建站点的升级验收清单
- 升级前做一次可恢复的备份，并确认备份文件能读出来；
- 升级后核对后台登录、角色与写权限是否与升级前一致；
- 核对伪静态地址与站点地图，确认历史链接没有大面积 404；
- 检查列表页的排序与筛选参数是否按预期返回；
- 轮换密钥类配置与管理员口令，避免沿用旧值；
- 把本次处置写进运维记录，包括公告口径与实际影响面。
常见问题
只修插件不修核心行不行？ 本轮问题在核心层，插件更新替代不了核心补丁，反过来也一样。
自动更新失败怎么判断？ 看版本号是否变化、后台是否仍提示待更新，失败时优先回退而不是反复重试。
老版本站点实在不能升级怎么办？ 把站点从公开访问里隔离出去，只保留必要页面，同时安排内容迁移，不要让它继续暴露写入入口。