安全公告连着发三条，站点升级要怎么排修补顺序

竞品核心安全公告连着发三条，站点升级该怎么排修补顺序？结论先给：不要按公告编号从前往后修，也不要只看等级高低。正确做法是把每条公告丢进三个问题里筛一遍——能不能远程触发、需不需要先拿到账号、你的站点是否真的启用了出问题的那块功能——筛完的结果再分成四档，安排进升级窗口。公开公告样本里，同一日发布的一条 Critical 远程代码执行与两条 Moderately critical 跨站脚本，正好是这套排法的典型输入。

同一天连着发三条说明了什么

同日多发包是发布节奏，不是威胁等级排序。厂商把攒在一个评审周期里的问题一起放出来，好处是站点只需要开一次升级窗口，代价是公告本身不告诉你先装哪一块。

三条公告通常落在不同模块上：远程代码执行那类集中在输入处理与字段渲染，跨站脚本那类集中在输出未充分转义。它们的影响面、触发路径、需要的前提条件完全不同，把它们当同一件事处理，就会把停机时间浪费在低危项上。

先用可达性筛，别用等级筛

严重等级衡量的是漏洞本身，不是你的站点暴露面。同一条 Critical，在一个没有启用对应模块的站点上，实际可达性接近零；反过来，一条Moderately critical 如果落在登录页这类人人可访问的入口上，就该往前提。

三个筛问按顺序问：

1. 能不能远程触发：需要已经在服务器上有账号，还是要匿名请求就能碰到问题代码。
2. 需不需要前提动作：比如要管理员点一下后台里的某个页面才成立，风险就比直接请求接口低一档。
3. 站点是否启用：出问题的那个组件在你自己的站点上是不是打开状态，这决定要不要马上排停机。

修补顺序怎么分四档

筛完的结果按下面四档排，档内按发布日期从新到旧处理。

甲档和乙档通常放在同一次窗口里做，因为补丁本身是一起发布的，分开跑反而多开一次停机。丙档的做法是把该功能确认在关闭状态并记入检查表，而不是马上升级。

升级窗口前要准备哪两样

一是备份。数据与静态文件都要覆盖到，且要验证过能恢复，不能只看备份任务显示成功。备份与恢复能力本身就是为这个场景准备的：升级出问题时的回退点，靠的是恢复演练而不是重试安装。

二是权限收紧清单。全站级操作——备份、升级、多站点这类会一次影响所有站点的动作——应当默认关闭，需要时显式开启再关掉。升级窗口里操作者多、自动化脚本多，默认关闭能避免在这个时段顺手执行了不该执行的批量操作。

自己这套系统该看哪几项

对照到 AnQiCMS，v3.6.6 的修复项正好是甲档形态：列表排序参数 SQL 注入属于匿名请求就能打到查询层的入口，站点切换登录凭证可被伪造属于能直接换掉身份的问题。前者靠参数化绑定收敛注入路径，后者把可复用的凭证改成一次性票据。

内置的 JWT 认证、内容敏感词过滤与防采集干扰码，是常态化的防线，不是补丁的替代品。已经在这类入口上跑公开表单的站点，升级之外还要检查后台的 SQL 注入与 XSS 相关日志有没有异常记录。

常见问题

只有等级高但没有启用对应模块，要不要马上停机升级

不用。按丙档处理，先确认模块处于关闭状态并记录，把升级留到常规窗口。要防的是后续误开启，而不是当前补丁本身。

跨站脚本类公告能不能只做减害不升级

可以做临时减害，例如收紧后台内容的输出转义、限制富文本标签白名单，但这些都是过渡。补丁落地后的抽查不能省，脚本类问题常在改写路径上复发。

一次窗口装多条公告，出问题怎么定位

靠回退点定位，不靠猜。升级前留存可恢复的备份，恢复演练走通后再开窗，出现异常按备份回退，而不是在窗口里逐条试。