v3.6.6 修复的列表排序参数注入会不会影响老站点
v3.6.6 修复的列表排序参数注入会不会影响老站点，答案是只要还停在旧版本，这段风险就在。漏洞位置不是新加的功能，而是列表查询里把排序参数拼进语句的那一处，任何版本的列表接口都会经过它；v3.6.6（2026 年 10 月 8 日发布）修掉的是列表排序参数注入与站点切换登录凭证可被伪造两项高危问题，所以”老站点没做过改动”不能作为不受影响的理由。
排序参数为什么难防
普通查询条件可以用参数化绑定把值与语句分开，排序位却常常不能直接参数化：列名与排序方向要参与语句结构，不能当作值传进去。于是不做校验的实现容易把外部传入的字段名原样拼接，形成注入面。常见写法是把允许的排序字段列成白名单，命中才使用，未命中回退到默认列，把外部输入变成”选一个已知项”而不是”写一段语句”。JWT 认证解决的是身份，敏感词过滤与干扰码解决的是内容层，这一类输入校验要单独做。
影响面怎么自查
自查按三条线走。第一条是接口线：所有能返回列表的入口，包括分类页、搜索页、标签页与后台列表，都检查是否接受外部排序参数、参数是否落在白名单内。第二条是模板线：模板里调用列表时如果把参数名透传出去，等于把注入面挪到前台，需要逐个核对模板标签的取值方式。第三条是日志线：看历史请求里有没有出现异常字段名、引号、注释符与拼接痕迹，这类请求未必成功，但能说明有没有被人试过。
升级窗口该做的四件事
| 顺序 | 动作 | 判断依据 | 遗漏时的后果 |
|---|---|---|---|
| 一 | 完整备份数据库与静态文件，并验证可还原 | 能否在新目录恢复出可访问站点 | 升级出问题时无路可退 |
| 二 | 在测试环境跑列表、搜索、后台筛选三类动作 | 排序与筛选结果是否与升级前一致 | 自定义模板的排序调用可能失效 |
| 三 | 升级后轮换站点签名密钥并更新管理员登录口令 | 旧凭证是否还可能被复用 | 站点切换时的凭证伪造风险仍在 |
| 四 | 一次性票据与登录流程复查 | 登录态是否按预期过期 | 会话长期有效扩大影响半径 |
升级后异常如何回退
回退的前提是备份可用，而不是重装旧版本。出现问题时按顺序处理：先把外部访问切到维护状态，避免风险继续被利用；再从备份恢复数据与文件，恢复到升级前的状态；然后核对是哪一处自定义改动与新版本冲突，把改动单独适配；确认可用后再走一次完整的升级流程。没有演练过的备份不能算备份，这一步在很多站点上是事后才补的。
老站点要不要为这一项单独评估
如果站点里存在多套模板或历史遗留的自定义列表调用，升级前要额外检查这些调用有没有直接传排序字段；这类代码不会因为升级自动改变行为，却可能在新校验下报错。改法是把传字段名改成传枚举值，由程序决定实际列名。至于”只跑内容展示、没有前台列表参数”的站点，风险相对有限，但凭证伪造那一项与列表无关，仍然建议按版本升级处理，不要因为改动小就长期停在旧版本上。
常见问题
升级会影响已经收录的 URL 吗？ 不会改变伪静态规则与地址结构，列表页地址保持原样。如果同时调整了排序参数命名，注意别把带参数的历史地址一起改掉。
只改配置能不能规避这个注入？ 不能替代升级。收紧入口、限制可访问的列表接口属于减害动作，修复本身在版本里。
升级后为什么要连签名密钥一起换？ 因为漏洞涉及凭证可被伪造，旧密钥签出的凭据在换密钥之后即失效，这一步是把历史风险一次性截断，和改管理员登录口令同样属于必要动作。
多久检查一次这类版本公告？ 建议按月固定复查一次安全公告与版本记录，同时把备份与回退演练排进同一周期，避免公告来了才发现没有可用的还原点。