CVSS 9.8 的 WordPress 核心漏洞通告，站点负责人该怎么按评分排优先级
安全通告里 CVSS 9.8 分的 WordPress 核心漏洞，站点应该怎样据此安排修复优先级？分数给出的是「漏洞本身多严重」的参考系，队列顺序却要按分数乘以暴露面来排：同样的高危漏洞，未认证攻击者就能在对外页面上触发的，要放在队列最前。以 WordPress Core 的 XSS2Shell 漏洞通告为例，把读法拆开讲。
通告里的四个关键信息
| 要素 | 通告内容 | 读的时候看什么 |
|---|---|---|
| 编号与评分 | CVE-2026-64638，CVSS 3.1 为 9.8 | 定严重等级 |
| 威胁类型 | 预认证跨站脚本升级为远程代码执行 | 攻击链会升级，别只当脚本问题 |
| 影响版本 | 6.4 至 7.0.2，7.0.3 修复 | 自家站点是否在区间内 |
| 在野利用 | 未发现 | 影响紧迫感，不改变等级上限 |
四项都是通告原文数据。第一步永远是拿影响版本区间对照自己的版本号，不在区间的降级处理，在区间的进入下一步。
CVSS 分数高和低分别说明什么
评分从认证要求、操作复杂度、影响范围几个维度合成，9.8 落在高危区间，意味着攻击链几乎不设门槛。但评分不回答「你被打的概率」：站点若关闭了注册、评论区不对外开放、相关功能形态没有启用，实际暴露面就小。合理的用法是：分数定上限，暴露面定先后。
评分之外还要看暴露面
三件事接着看：认证门槛——预认证意味着攻击者不需要账号；可达性——漏洞入口是否暴露在外网，登录页、评论区开放与否直接改变风险；兜底能力——系统是否有内置的 XSS 与 SQL 注入防护、内容过滤这类防线，为补丁落地争取时间。AnQiCMS 内置 JWT 认证、敏感词过滤与防采集干扰码，思路一致：单点修复跟公告走，日常防线不靠某个补丁。
排不出优先级时的兜底动作
人手不足、修复要等窗口时，先做三件事：收紧能触发漏洞的入口，评论转先审后发、注册转人工审核；给对外表单和登录入口加 reCAPTCHA 验证码，挡住无人值守的自动化尝试；把备份做在前面并验证可恢复，真出问题时能整体退回。兜底的逻辑不是赌这个漏洞不被用，而是把可利用面压到最小，给补丁争取时间。
常见问题
问：CVSS 9.8 一定比 7.5 先修吗？ 答：两个都落在暴露面上时，9.8 先行；9.8 的触发路径在自家站点是关的，而 7.5 的入口大敞着，就先处理 7.5。分数定上限，暴露定顺序。
问：通告写「未在野利用」，能多等几天吗？ 答：可以换来缓冲期，前提是漏洞入口已被收紧，且缓冲有明确截止时限，而不是无限期搁置。
问：内容侧防御对代码执行类漏洞有用吗？ 答：不替代修复，但减链路损害：敏感词过滤与内容审核管得住被存储的内容，验证码与认证机制管得住未认证的写入路径，正好覆盖此类漏洞的入口段。