LiteLLM ha pubblicato due release a cinque minuti di distanza nelle prime ore del 23 agosto: v1.99.0-rc.1, una prerelease, alle 00:23 UTC, e v1.98.0, la stabile, alle 00:28 UTC. Le note della release stabile elencano una correzione di autenticazione. Il commit che ha annullato quella correzione è nella stessa cronologia.

Cosa risolveva la correzione

La PR #36837 si intitola “fix(auth): stop the team fallback from widening model access”. LiteLLM determina a quali modelli può accedere un chiamante anche in base al record del suo team. Quando la ricerca del team fallisce, il codice ricorreva ai campi contenuti nel token stesso — e in quel percorso di fallback una lista team_models vuota viene letta come autorizzazione per tutti i modelli invece che per nessuno. La correzione trasformava un team mancante in un rifiuto netto.

Perché è stata annullata

La Admin UI firma la chiave di sessione con un ID team segnaposto, litellm-dashboard, che intenzionalmente non ha alcuna riga nel database. La correzione interpretava quella riga assente come una condizione di rifiuto, così ogni richiesta alla dashboard restituiva 404 e ogni amministratore veniva bloccato fuori. La PR #36982 l'ha annullata il 14 agosto, ripristinando il fallback derivato dal token.

La distorsione: una voce di changelog non è uno stato distribuito

Leggere le note di v1.98.0 dice che la falla del fallback del team è chiusa. Leggere la cronologia dei commit dice che la correzione è stata introdotta, ha mandato in crash la dashboard ed è stata riportata indietro nove giorni prima che quella release fosse pubblicata. Entrambi i fatti sono pubblici; solo uno è nel changelog. È il rischio generale di trattare le release note come un registro di sicurezza: documentano ciò che è stato unito, non ciò che è sopravvissuto.

Il revert è esplicito su ciò che costa

Non si presenta come una correzione. La descrizione afferma che ripristina il fallback derivato dal token per correggere la regressione riconoscendo però che così riapre la falla di sicurezza legata all'ampliamento dell'accesso ai modelli, e che serve una reimplementazione più attenta. È una nota insolitamente chiara da lasciare in un revert, ed è proprio la parte che non compare nella pagina della release.

Cosa dovrebbero verificare gli operatori

Se nel release candidate v1.99.0 sia presente una reimplementazione corretta non può essere stabilito dalle note pubbliche della release, e qui non viene affermato. Chiunque faccia affidamento su restrizioni ai modelli basate sul team dovrebbe testare il comportamento nel proprio deployment — in particolare, cosa può effettivamente chiamare una chiave con un team non risolvibile e una lista di modelli vuota — invece di inferirlo da una riga di changelog.