AnQiCMS v3.6.6安全升级：修复排序参数注入与登录凭证伪造漏洞
AnQiCMS v3.6.6 版本修复了哪些高危安全问题？这一版在 2026-10-08 发布，处理的是两条登录与数据访问链路上的高危问题：列表排序参数存在 SQL 注入风险，以及站点切换场景下登录凭证可被伪造。两条都不需要管理员权限作为前提，因此升级动作不能只停在换版本，还要把签名密钥轮换和管理员密码修改一起做完。
排序参数注入是怎么发生的
内容后台的列表页普遍支持按时间、按浏览量等字段排序，排序字段与排序方向通常由前端请求参数传入。如果这些参数被直接拼进查询语句，攻击者就能把构造的值塞进去，读到本不该返回的数据，这就是列表排序参数的 SQL 注入。这类问题的隐蔽性在于「功能看起来完全正常」，只靠观察页面行为发现不了，必须靠参数化绑定与输入校验在代码层收口。
排查时可以按这个顺序自查：所有带排序、筛选的列表接口是否走同一层参数校验；是否还有手写 SQL 的查询路径；数据库账号权限是否收敛到只需要用到的能力。v3.6.6 已经把排序参数这条路径修掉，但历史**问过该接口的记录仍值得回看一次。
站点切换时凭证可被伪造意味着什么
多站点管理允许在一个后台里切换不同站点，切换动作依赖系统内部签发的凭证。这一版修复的问题在于该类凭证可被伪造，等价于拿到进门的票据就能冒充合法身份，且伪造出来的凭证与真实签发的外观没有区别。这也是升级建议里要求轮换全站请求的签名密钥的原因：只升级代码，不轮换密钥，已经泄露出去的签名材料仍然可能被继续使用。
配套的处置是修改管理员密码，改的是人持有的那道门，与签名密钥轮换分别覆盖「服务端材料」和「用户侧凭证」两个面。两者要一起做，缺一项都会留下可用的旧路径。这里要强调，签名密钥与管理员密码都不应出现在工单、聊天记录或代码仓库里，轮换动作本身也只留操作记录，不留明文。
升级与处置的顺序
按以下顺序做，能把风险窗口压到最短：
- 先做一次包含静态文件的备份，AnQiCMS 的备份与恢复支持数据（含静态文件）备份和恢复，升级出问题时能退回可用状态。
- 升级到 v3.6.6，确认版本号与更新记录一致。
- 轮换全站请求的签名密钥，覆盖所有站点。
- 修改管理员密码，并检查是否存在异常账号与异常登录记录。
- 回看列表接口的访问日志，确认排序参数的调用是否出现可疑形态。
需要提醒的是，第 1 步不是形式。历史上「升级失败只能重建站点」的情况，多数源于升级前没有可用备份。
与其他安全能力的关系
这一版修的是访问控制与查询构造层，与系统内置的其他防线是互补关系。AnQiCMS 内置 JWT 认证、内容敏感词过滤与防采集干扰码，用于防御 SQL 注入和 XSS 攻击；表单侧可以接入 reCAPTCHA 验证码防机器人提交。安全能力的价值在于叠加：修掉注入路径、限制自动化提交、过滤不合规内容，三者共同决定实际暴露面，单独看任何一项都会低估风险。
对运营团队的建议是把版本公告当成巡检项：订阅发布记录，出现高危修复时按上述顺序处置，而不是攒到季度更新一起做。
常见问题
只升级到 v3.6.6，不轮换签名密钥可以吗？ 不建议。修复代码解决的是伪造能力，已暴露的签名材料仍可能被继续尝试使用，轮换密钥才是把旧路径关掉的动作。
修改管理员密码会影响正在编辑的内容吗？ 不影响内容数据，影响的是登录状态。改密后所有会话需要重新登录，建议安排在无人发布的时间点执行。
怎么确认自己站点已经用上了修复版本？ 看后台版本信息与更新记录是否显示 v3.6.6；线上环境还可以结合发布说明核对修复项描述，避免只更新了前端资源而未替换二进制。