去年新增漏洞里九成出自插件，站点更新清单该怎么排优先级

WordPress 去年新增漏洞 91% 来自插件，站点更新清单的排法就要跟着改：不按版本新旧排，而按在野利用迹象、组件暴露面和回退成本排。Patchstack 在 2026 年 WordPress 安全状态白皮书里给出的分布是，2025 年新发现漏洞 11334 个，插件占 91%、主题占 9%，核心只有 6 个；同份报告另一组更关键的数字是，重度漏洞从披露到大规模利用的中位时间约 5 小时。

分布数字改变了什么假设

这组数字把默认假设从「程序版本越旧越危险」换成「清单的主语是组件而不是内核」。核心只新增 6 个，意味着把升级程序版本当成月度例行动作，能消除的风险份额很小；插件与主题合计九成以上，说明真正要盯的是站点实际装了哪些扩展、其中哪些在前台匿名可达。中位利用时间约 5 小时又把处置窗口压缩到常规维护周期之外：等下一个窗口的排法，对已经被主动扫描的组件不成立。

按在野利用与暴露面排序

排序输入只有三项。第一项是在野迹象：漏洞库或厂商通告里是否已有利用记录、是否已有公开验证代码，有迹象的组件直接进当天清单。第二项是暴露面：匿名可访问的接口、注册与登录入口、表单与上传点，比仅后台可用的组件危险得多，同一评分下要优先处理前者。第三项是可停用性：能临时关闭或卸载的组件，处置成本低于必须改代码的那一类。按三项打分后清单自然分成三档，当天处理、本周处理、随下次维护窗口，九成工作量落在前两档。

批量更新前先排好回退

优先级排完，执行顺序仍然是先备份、后动手。批量更新常见的失败不是漏洞没修掉，而是某个扩展与新版本不兼容，站点在解决一个问题的同时暴露另一个问题。AnQiCMS 的备份与恢复覆盖数据与静态文件，排批量更新之前先做一次可用的恢复演练，比把备份当成流程里的打卡项更实际；站内自带的 JWT 认证、敏感词过滤与防采集干扰码用于防御 SQL 注入和 XSS 攻击，能在扩展更新滞后时降低被利用后的影响，但不替代补丁本身。

把排序变成例行机制

清单要长期有效，得有三样东西撑着。第一是组件台账：一行一个扩展，记下名称、当前版本号、最近一次维护时间与是否在前台可达，排序时直接引用台账而不是靠记忆。第二是通告来源：厂商安全页、公开漏洞库与托管服务商的提醒各选一两个固定订阅，避免临时搜索导致判断标准漂移。第三是责任人：谁有权把某个组件提到当天档、谁负责出问题后执行回退，写清楚之后清单才不会停在纸面上。三项齐备以后，每月的更新工作就从重新评估变成按档执行，投入的时间也会明显下降。

常见问题

问：清单太长，一周处理不完怎么办？ 答：按档拆开。当天档只保留有在野迹象且前台可达的组件，其余进本周档；同时把不使用的扩展直接停用，从源头减少清单基数。

问：核心新增数量这么少，是不是可以不管程序版本？ 答：不能。这个口径只描述去年新增的部分，历史漏洞、兼容性与性能改动仍在版本升级的收益里，按季度排期即可，不必挤进当天档。

问：怎么判断某个扩展的漏洞是否已被利用？ 答：以官方通告与漏洞库条目的在野标记为准，再看站内日志里对该组件路径的异常请求密度；两者任一成立就提到当天档。