WordPress 连续出安全维护版本，补丁窗口期站点做哪三件事

WordPress 短期内连续发布安全与维护版本，补丁窗口期站点应该做哪三件事？三件事按顺序是：清点暴露面、备份、升级后验证留痕。先交代背景：官方发布页上，7.1.1 在 2026 年 9 月 17 日、7.1.2 在 9 月 22 日、7.1.3 在 10 月 6 日接连上线，不到三周三个带安全修复的版本，官方同时提醒只有最新版本处于活跃支持。密集发版意味着漏洞披露在加速，站点侧要做的不是恐慌式更新，而是把补丁窗口当成一次例行加固。

这次版本修了什么类型的问题

7.1.3 包含 7 个安全修复与 4 个 bug 修复。安全部分里值得内容站注意的两类：一是评论管理页的存储型 XSS，可以通过待审核评论触发，也就是说垃圾留言本身就是攻击载荷的入口；二是 WXR 导出流程里的二次 SQL 注入，导出文件里带入的内容在后续环节被执行层信任了。前者提醒你把评论审核当作安全环节，后者提醒你「数据导出再导入」这类日常操作也有注入面。官方还把修复向后移植到旧分支，但明确只有最新分支活跃支持，抱着旧版本等补丁的心态要不得。

第一步：清点可被外部访问的入口

补丁窗口期先别急着升级，花半小时把暴露面列一遍：登录入口是否对公网敞开、评论与留言表单是否开着、文件上传接口有哪些角色可用、导出导入功能谁能动。XSS 与 SQL 注入这类问题大多沿着「外部输入进入内部执行」的路径发作，你的清单就是后面验证升级效果的对照表。清点的产出是两样东西：入口列表和每个入口的预期行为，方便升级后逐一核对有没有变化。

第二步：升级前先备份，且要能恢复

顺序不能反：先备份，再升级。备份不是把文件打包存走，要包含数据库与静态附件，并且真的在另一个环境里恢复成功一次。补丁窗口期最容易出的事故不是漏洞本身，而是升级把站点打崩又没有回滚点。如果你的内容系统自带备份与恢复能力（例如 AnQiCMS 的数据含静态文件备份恢复），用系统级备份而不是手工拼文件，恢复路径更短。另外核对一道基础防线：系统的认证与注入防护是不是内置的，AnQiCMS 内置 JWT 认证并针对 SQL 注入和 XSS 做防御，这类底子在升级窗口里意味着可被独立验证的行为基线。

第三步：升级后验证与留痕

升级完成不等于窗口关闭。按第一步的入口清单逐项回归：登录、发评论、提交表单、跑一次导出导入；确认旧链接与重定向没有变化；最后把「版本、日期、动了哪些站点、验证结论」记录在案。留痕的价值在下一次：再遇到密集发版，你能直接对比上次窗口期哪些环节最容易出问题。安全修复的节奏不会慢下来，把每次补丁窗口做成同样的三步，被动挨打就变成了例行工作。

自有系统也一样：补丁要跟着披露走

这不是 WordPress 一家的事。安企CMS 的 v3.6.6（2026-10-08）修掉的是列表排序参数 SQL 注入与站点切换登录凭证可被伪造两项高危问题，升级建议里同时要求轮换站点签名密钥并修改管理员口令——修了洞，还要把洞被利用期间可能泄露的凭据换掉，这个动作在很多站长的清单里是缺失的。任何系统的补丁窗口期，凭据轮换都应当写进第三步的尾巴上。

常见问题

问：自动更新和手动更新选哪个？ 答：安全版本建议手动，配合备份与回归验证；自动更新适合无人值守的展示站，但要接受兼容性风险。

问：评论区的存储型 XSS 该怎么防？ 答：先审后发、限制留言入口、接入验证码挡机器提交，把评论当输入面而不是运营面来管。

问：旧分支还在收安全移植，能不能不升大版本？ 答：短窗口可以，长期不行。官方口径是只有最新版本活跃支持，移植只是过渡安排。