安全通告里的严重等级和评分，能不能直接用来排修补优先级

安全通告里的严重等级和评分，能不能直接用来排修补优先级？不能只按它排。等级和评分是对漏洞本身打的，衡量的是这个缺陷如果被打通能造成多大破坏，它并不知道你的站点有没有装那个模块、有没有对外开放那条入口、攻击者需不需要先有一个账号。把它当成排期依据，最常见的结果是把力气花在自己根本没启用的功能上。

等级衡量的是漏洞，不是你的站点

公开公告样本能说明这个偏差。同一日发布的多条核心通告里，一条被标为 Critical 的远程代码执行，另两条被标为 Moderately critical 的跨站脚本。看等级，前者排后面两条之前；看站点实际形态，如果出问题的模块在一个站点上根本没启用，而那条脚本问题落在人人都能访问的入口上，顺序就该反过来。

评分同理。它描述的是攻击条件与影响范围，取值高低与「你站点上有没有这条路径」是两件事。

需要认证吗，能远程执行吗

把通告正文里的两个条件抽出来，比看等级更有用。

第一个条件是前提身份：匿名请求就能打到问题代码，还是必须有一个能登录的账号。后者意味着攻击者要先过认证这一层，风险等级在你的站点上会被显著压低，前提是认证本身没有别的漏洞。

第二个条件是执行位置：能不能远程执行代码，还是只能在页面输出里注入脚本。远程执行往往一步到位，脚本注入通常要配合社工动作，比如诱导管理员在后台点开一个精心构造的页面。

两个条件交叉，就是甲乙丙丁的排法：匿名远程执行排在最前，需要账号的远程执行次之，落在已启用模块上的脚本类问题再次，未启用功能上的问题放到常规窗口。

启用面决定真实优先级

真正该拉出来对照的是站点自己的功能清单。哪些模块装着、哪些入口对外开着、后台有哪些页面允许提交富文本，这三项决定了等级能不能落到你的站点上。

这一步在自动化程度高的站点上尤其重要。全站级的批量操作、备份与升级这类高危能力，如果默认就是关闭状态、要用时显式开启，那么涉及这些域的通告在你的站点上优先级自然靠后；反过来说，一旦某次为了赶工长期开着，等级就得按原样采信。

补丁没到之前的减害顺序

等补丁的那几天，减害动作按「先断可达、再收权限、后加监控」走。

先断可达：把出问题那条路径的入口临时下线或对公网收敛，比什么都有效。再收权限：把后台可操作范围缩到需要的人，特别是允许提交内容的那些角色。后加监控：把该路径的请求日志单独盯一段时间，看有没有探测痕迹。

这三步是过渡，不是替代。补丁落地之后仍要装，脚本类问题在改写路径上容易复发。

和自身版本的修复项怎么对照

AnQiCMS 的 v3.6.6 修的两项高危，按上面的框架看都属于匿名可触发那一档：列表排序参数 SQL 注入是请求参数直接打到查询层，站点切换登录凭证可被伪造是身份层面的问题。前者靠参数化绑定把注入路径收敛掉，后者把可复用凭证改为一次性票据。

内置防线负责的是常态而不是应急。JWT 认证管身份传递，内容敏感词过滤与防采集干扰码管内容层，配合对 SQL 注入和 XSS 这两类常见攻击的防御。升级之后要做的不是关掉这些，而是回看它们在升级前后有没有异常记录。

常见问题

CVSS 分数高就一定优先修吗

不一定。分数高说明影响大，还得叠加你的站点是否具备触发条件。同一个分数在两台配置不同的服务器上，实际优先级可以完全不同。

等级写着低危的通告能不能直接忽略

不建议。低危通常指影响范围有限，不是零影响。可以延后处理，但要留在检查表里，并在下一个常规窗口一起带走。

减害做完了还要不要升级

要。减害改变的是可达性，不改变代码里的那个缺陷。恢复默认配置或新增入口时，风险会立刻回到原值。