LiteLLM publicó dos versiones con cinco minutos de diferencia a primera hora del 23 de agosto: v1.99.0-rc.1, una versión preliminar, a las 00:23 UTC, y v1.98.0, la estable, a las 00:28 UTC. Las notas de la versión estable incluyen una corrección de autenticación. El commit que deshizo esa corrección está en el mismo historial.

Qué abordaba la corrección

La PR #36837 lleva por título “fix(auth): stop the team fallback from widening model access”. LiteLLM determina a qué modelos puede acceder un usuario en parte a partir del registro de equipo de ese usuario. Cuando la búsqueda del equipo falla, el código recurría a los campos transportados en el propio token —y, en esa ruta de fallback, una lista vacía team_models se interpreta como permiso para todos los modelos, en lugar de para ninguno. La corrección convirtió la ausencia de equipo en una denegación tajante.

Por qué se revirtió

La interfaz de administrador firma su clave de sesión con un ID de equipo señuelo, litellm-dashboard, que intencionalmente no tiene fila en la base de datos. La corrección trataba esa fila ausente como una condición de denegación, así que todas las solicitudes del panel devolvían 404 y todos los administradores quedaban bloqueados fuera. La PR #36982 la revirtió el 14 de agosto, restaurando el fallback derivado del token.

La distorsión: una entrada del registro de cambios no es un estado desplegado

Leer las notas de la v1.98.0 indica que el agujero del fallback de equipo está cerrado. Leer el historial de commits indica que la corrección llegó, rompió el panel y se retiró nueve días antes de que se publicara esa versión. Ambos hechos son públicos; solo uno aparece en el changelog. Ese es el riesgo general de tratar las notas de lanzamiento como un registro de seguridad: documentan lo que se fusionó, no lo que sobrevivió.

La reversión es explícita sobre lo que cuesta

No se presenta como una corrección. La descripción afirma que restablece el fallback derivado del token para reparar la regresión al tiempo que reconoce que hacerlo reabre el agujero de seguridad en torno a la ampliación del acceso a modelos, y que hace falta una reimplementación más cuidadosa. Es una nota inusualmente clara para dejar en una reversión, y precisamente esa es la parte que no aparece en la página de la versión.

Qué deberían verificar los operadores por su cuenta

No puede establecerse a partir de las notas públicas de la versión si en el release candidate v1.99.0 está presente una reimplementación corregida, y aquí no se afirma tal cosa. Quien dependa de restricciones de modelos acotadas por equipo debería probar el comportamiento en su propio despliegue —en concreto, qué se le permite llamar realmente a una clave con un equipo no resoluble y una lista de modelos vacía— en lugar de inferirlo a partir de una línea del changelog.