一次版本更新修掉排序参数注入和登录凭证可被伪造，密钥为什么要一起换

v3.6.6 这次版本更新修掉了两类高危问题：列表排序参数被拼进查询语句形成的 SQL 注入，以及多站点之间切换用的登录凭证可被伪造。官方升级建议里同时要求轮换站点签名密钥、修改管理员口令。很多管理员的疑问在于：程序都升级了，漏洞入口不是已经封死了么，密钥为什么还要换？答案是一句话——升级关闭的是「再被这样打进来」的门，管不了「已经配好钥匙的人」，凭证轮换做的正是后者。

两个高危分别影响什么

排序参数注入的风险面在数据。列表页按时间、按热度排序，排序字段与方向这类参数从地址或请求里来，程序若把它不经校验地拼进查询片段，构造的请求就能改变查询本意，读走边界外的数据。它隐蔽的地方在于参数看起来人畜无害，日常访问与攻击流量在日志里长得很像。

站点切换凭证可被伪造的风险面在访问边界。一套后台管多个站点时，从 A 站切到 B 站需要一个「证明你有资格」的凭据；如果这个凭据的构造方式可被推算或伪造，攻击者拿到的不是某一篇内容，而是跨站点的操作位。这类问题的严重性通常高于单页数据泄露，因为它动摇的是「谁能进来」这个前提。

修入口不等于清会话

升级后，程序对新请求按修复后的逻辑处理：排序参数走白名单校验，切换凭证按更稳妥的方式签发——例如用短期有效、用过即废的一次性票据，而不是可长期推算的固定密钥。但对已经存在的存量风险，升级本身不做两件事：其一，漏洞在被修复前若已被利用，留下的登录态、被改过的配置不会因升级自动复原；其二，旧签名机制下已经签发、可能已经外流的凭证，不会因为代码更新就凭空失效。这就是「修入口」与「清会话」的区别：门修好了，先前配出去的钥匙还得单独作废。

轮换密钥这一步防的是什么

轮换站点签名密钥，等于把所有旧机制签发的凭证一次性作废：新密钥签发的凭证才被承认，拿旧方式伪造出来的东西从轮换生效那一刻起全部无效。改管理员口令针对的是另一条线——口令这类凭据一旦外泄，改之前它一直好使，改之后旧值即刻失效。两项动作成本都是分钟级，收益却是把「历史上是否泄露过」这个无法回答的问题，转换成「泄露了也不再有效」。这也是为什么 v3.6.6 的升级建议把它们并列提出：修代码解决成因，换凭证清理后果。

升级窗口的三步

按顺序把动作排进同一个窗口：先做一次数据备份（含静态文件），升级出问题可以整体回退，这是任何安全版本跟进的第一步；随后完成升级并确认版本号已到位；紧接着执行密钥轮换与管理员口令修改，并顺带核查两件事——列表排序类参数是否还有拼接痕迹的定制代码，后台账号里是否存在不认识的管理员。窗口收尾时把访问日志中升级前后的异常请求做一次比对，确认没有遗留的会话还在活动。整套动作做完，修复才算闭环，而不是只把程序文件换成了新版。

常见问题

问：不轮换密钥，只升级可以吗？
答：技术入口被封，但旧机制下签发、可能已外流的凭证仍然有效，风险没有被清理干净，官方建议不建议拆开执行。

问：怎么知道站点有没有被排序参数注入利用过？
答：重点回看后台与列表接口的异常访问记录：非常规参数形态、批量拉取、返回异常的数据请求，比对升级前后的差异。

问：多站点规模大，轮换会不会影响在线业务？
答：轮换主要影响重新签发过程，在线会话按各站机制处理，安排在低峰窗口执行即可。

问：这次修复和内置的 JWT、干扰码等防护是什么关系？
答：那类是常态化防线，本次是具体成因的修复；两者不互相替代，升级后所有防线照常生效。