LiteLLM cut two releases within five minutes of each other early on 23 August: v1.99.0-rc.1, a prerelease, at 00:23 UTC, and v1.98.0, the stable, at 00:28 UTC. The stable release notes list an authentication fix. The commit that undid that fix is in the same history.
What the fix addressed
PR #36837 is titled “fix(auth): stop the team fallback from widening model access”. LiteLLM resolves which models a caller may reach partly from that caller's team record. When the team lookup fails, the code fell back to fields carried on the token itself — and in that fallback path an empty team_models list reads as permission for every model rather than none. The fix turned a missing team into a hard refusal.
Why it was reverted
The Admin UI signs its session key with a sentinel team ID, litellm-dashboard, which intentionally has no database row. The fix read that absent row as a refusal condition, so every dashboard request returned 404 and every administrator was locked out. PR #36982 reverted it on 14 August, restoring the token-derived fallback.
The distortion: a changelog entry is not a deployed state
Reading v1.98.0's notes tells you the team-fallback hole is closed. Reading the commit history tells you the fix landed, broke the dashboard, and was rolled back nine days before that release was cut. Both facts are public; only one is in the changelog. This is the general hazard of treating release notes as a security ledger — they record what was merged, not what survived.
The revert is candid about what it costs
It does not present itself as a fix. The description states that it restores the token-derived fallback to repair the regression while acknowledging that doing so reopens the security hole around model-access widening, and that a more careful re-implementation is needed. That is an unusually clear note to leave in a revert, and it is precisely the part that does not surface on the release page.
What operators should verify themselves
Whether a corrected re-implementation is present in the v1.99.0 release candidate cannot be established from the public release notes, and is not asserted here. Anyone relying on team-scoped model restrictions should test the behaviour against their own deployment — specifically, what a key with an unresolvable team and an empty model list is actually permitted to call — rather than inferring it from a changelog line.