LiteLLM 在 8 月 23 日清晨在彼此相隔五分钟内发布了两个版本：v1.99.0-rc.1，预发布版，于 00:23 UTC 发布，以及 v1.98.0，稳定版，于 00:28 UTC 发布。稳定版发行说明列出了一项认证修复。撤销该修复的提交也在同一段历史中。
这项修复解决了什么问题
PR #36837 的标题是“fix(auth): stop the team fallback from widening model access”。LiteLLM 会部分依据调用者的团队记录来判断其可访问哪些模型。当团队查询失败时，代码会回退到令牌本身携带的字段——而在这一回退路径中，空的 team_models 列表会被解读为允许访问 所有 模型，而不是没有任何模型。此次修复将缺失团队的情况改为直接拒绝。
为何它被回滚
Admin UI 用一个哨兵团队 ID litellm-dashboard 为其会话密钥签名，该 ID 刻意没有数据库记录。这项修复将这个缺失记录视为拒绝条件，因此每个仪表板请求都返回 404，所有管理员都被锁在外面。PR #36982 于 8月14日 将其回滚，恢复了基于令牌的回退逻辑。
这种失真：更新日志条目不等于已部署状态
阅读 v1.98.0 的说明会让你以为团队回退漏洞已经被堵上。查看提交历史则会发现，这项修复曾被合并、破坏了仪表板，并在该版本发布前九天被回滚。这两个事实都公开可查；但只有一个会出现在更新日志里。这就是把发行说明当作安全账本时普遍存在的风险——它们记录的是已经合并了什么，而不是最终保留下来的是什么。
回滚说明坦率承认了代价
它并没有把自己描述成修复。说明中写道，它恢复了基于令牌的回退逻辑，以修复这一回归，同时承认这样做会重新打开围绕模型访问扩大的安全漏洞，并且需要更谨慎的重新实现。这是在回滚说明中留下的异常清晰的注释，而这恰恰是发布页面上看不到的部分。
运营方应自行核实什么
从公开发行说明中无法确定 v1.99.0 release candidate 中是否已经存在修正后的重新实现，这里也不对此作断言。任何依赖按团队范围限制模型访问的用户，都应在自己的部署环境中测试其行为——具体来说，就是一个团队无法解析且模型列表为空的密钥，实际上被允许调用什么——而不是根据更新日志中的一行文字作出推断。