官网公告里出现 SQL 注入修复字样时，站点要做哪三步

公告里出现「SQL 注入修复」字样时，站点要做的不是立刻升级，而是三步：先把公告拆成受影响面与触发条件，确认问题出在哪个入口；再判断这次修复是否伴随凭证轮换动作，需要时先轮换全站请求签名密钥并修改管理员口令；最后把升级安排进低峰窗口，并按受影响的入口做回归验证。以 AnQiCMS（安企内容管理系统）v3.6.6 为例，这一步顺序尤其重要，因为该版本处理的两类高危问题，只升级代码并不能收口。

第一步：把公告拆成受影响面与触发条件

读公告时最有用的信息不是「修复了漏洞」，而是三件事：哪个入口、需要什么条件才能触发、影响到哪些数据。AnQiCMS 在 2026-10-08 发布的 v3.6.6 修复了两项高危问题：列表页排序参数相关的 SQL 注入，以及站点切换登录凭证可被伪造。两条的可读结论不同——排序参数属于列表查询这条链路，触发面取决于列表接口是否对外；站点切换凭证属于认证与会话层，一旦被伪造，影响范围直接跨站点。

拆分时按这张清单核对：入口是否对外、触发是否需要已登录、是否涉及跨站点或全站级数据、有无公开的验证代码。四项里任何一项落在「对外且无需登录」，处置窗口就要压缩到小时级。

第二步：轮换与改密的顺序

升级代码解决的是「漏洞不再存在」，但不解决「已经有人拿到过东西」。所以顺序是：先轮换与升级，再验证有没有残留风险。具体动作分三项。第一项，轮换全站请求签名密钥——签名密钥变更后，此前伪造出来的登录凭证随之失效，这是这类凭证类问题的收口方式，v3.6.6 的升级建议里明确要把这一步和升级一起做。第二项，修改管理员口令，并检查管理员账号有没有异常新增。第三项，检查登录会话与站点切换相关配置，只保留必要的暴露范围。

这一步最容易被漏掉的不是操作本身，而是漏掉「只升级不轮换」的后果：代码更新后旧凭证仍然可用，攻击面并未关闭。

第三步：升级窗口与回归验证

高危修复要抢时间，但更要把可回滚条件准备好。上线前先做一次覆盖数据与静态文件的备份，恢复点选在升级前的最近一次内容更新之后，这样出问题能整站回退。升级放在低峰窗口，完成后按公告提到的入口逐条回归：列表排序参数带上异常值时不再改变查询行为、后台登录与站点切换流程正常、内容列表与详情页返回一致。

回归之后补两项常态化检查：把版本更新公告纳入固定订阅，出现高危字样时有人负责判断；把密钥轮换与口令更换写进运维记录，避免下次要轮换时找不到当前值是从哪来。

哪些情况说明不能只升级代码

三类信号。一是公告同时给出「建议轮换密钥、修改管理员密码」这类补充动作——说明问题的影响面覆盖到凭证，代码修复只是收口的一半。二是受影响入口长期对外，且无法确认访问日志是否干净。三是修复涉及认证、签名或跨站点能力，这类改动通常伴随配置项变化，只换代码不改配置会留下旧行为。

反过来，如果公告属于低风险的显示或兼容问题，且触发需要已登录的后台权限，那按版本节奏升级即可，不需要临时打乱发布计划。

常见问题

问：看到 CVE 编号但看不到细节，怎么判断风险？ 答：按四个可读维度判断——入口是否对外、是否需登录、是否涉及全站级数据、有无公开验证代码。缺细节时先按保守假设处置，同时把备份与日志留存做到位。

问：升级前必须先做备份吗？ 答：是。支持数据与静态文件备份的系统，升级前先做一次，回滚才可行；否则出问题只能重建，代价远高于延迟几小时升级。

问：能不能只关闭列表功能来临时规避？ 答：可以作为临时措施，但要清楚这是缩小暴露面而不是消除问题，仍需在最近窗口内完成版本升级与密钥轮换。