LiteLLM a publié deux versions à moins de cinq minutes d’intervalle au petit matin du 23 août : v1.99.0-rc.1, une préversion, à 00:23 UTC, et v1.98.0, la version stable, à 00:28 UTC. Les notes de version de la version stable mentionnent un correctif d’authentification. Le commit qui a annulé ce correctif figure dans le même historique.
Ce que le correctif visait
La PR #36837 est intitulée « fix(auth): stop the team fallback from widening model access ». LiteLLM détermine quels modèles un appelant peut atteindre en partie à partir de l’enregistrement d’équipe de cet appelant. Lorsque la recherche d’équipe échoue, le code retombait sur les champs transportés par le jeton lui-même — et, dans ce chemin de repli, une liste team_models vide est interprétée comme une autorisation pour tous les modèles plutôt que pour aucun. Le correctif transformait une équipe introuvable en refus explicite.
Pourquoi il a été annulé
L’interface d’administration signe sa clé de session avec un identifiant d’équipe sentinelle, litellm-dashboard, qui n’a volontairement aucune ligne en base de données. Le correctif interprétait cette absence de ligne comme une condition de refus, si bien que chaque requête du tableau de bord renvoyait un 404 et que tous les administrateurs se retrouvaient bloqués. La PR #36982 l’a annulé le 14 août, rétablissant le fallback dérivé du jeton.
La distorsion : une entrée de changelog n’est pas un état déployé
Lire les notes de la v1.98.0 vous dit que la faille du fallback d’équipe est fermée. Lire l’historique des commits vous dit que le correctif a été intégré, a cassé le tableau de bord, puis a été retiré neuf jours avant la publication de cette version. Ces deux faits sont publics ; un seul figure dans le changelog. C’est le risque général qu’il y a à traiter les notes de version comme un registre de sécurité : elles consignent ce qui a été fusionné, pas ce qui a survécu.
Le revert est explicite sur son coût
Il ne se présente pas comme un correctif. Sa description indique qu’il rétablit le fallback dérivé du jeton pour corriger la régression tout en reconnaissant que cela rouvre la faille de sécurité liée à l’élargissement de l’accès aux modèles, et qu’une réimplémentation plus prudente est nécessaire. C’est une note exceptionnellement claire à laisser dans un revert, et c’est précisément la partie qui n’apparaît pas sur la page de publication.
Ce que les opérateurs devraient vérifier eux-mêmes
On ne peut pas établir à partir des seules notes de version publiques si une réimplémentation corrigée est présente dans la version candidate v1.99.0, et rien de tel n’est affirmé ici. Toute personne qui s’appuie sur des restrictions de modèles à l’échelle d’une équipe devrait tester le comportement sur son propre déploiement — en particulier, ce qu’une clé associée à une équipe impossible à résoudre et à une liste de modèles vide est réellement autorisée à appeler — plutôt que d’en déduire la réponse à partir d’une ligne de changelog.