Le tue API key potrebbero essere state esposte?
A ottobre 2026 sono emersi tre incidenti che riguardano segreti dei clienti: le variabili d'ambiente di Railway, la versione 1.107.0 di LiteLLM con un ladro di credenziali e le API key cifrate di TiDB Cloud.
Facciamo l'inventario dei vostri segreti, li ruotiamo in un ordine che taglia prima il rischio maggiore, revochiamo i vecchi, verifichiamo se qualcuno li ha usati e li spostiamo in un secret manager con token a vita breve.
# Quale versione di LiteLLM è installata?$ pip show litellm | grep -i ^versionVersion: 1.107.0# La 1.107.0 è la versione malevola pubblicata il 21-ott su PyPI e Docker Hub$ docker images | grep -i litellm$ grep -rn "litellm" requirements*.txt pyproject.toml poetry.lock uv.lock 2>/dev/null# Fissa l'ultima versione sana nel lockfile e nelle immagini$ pip install "litellm==1.106.2"# Fissare la versione non ripulisce la macchina: ruota i segreti a cui aveva accessoTre incidenti, lo stesso compito in sospeso
In tutti e tre i casi il fornitore ha fatto la sua parte e la rotazione di ciò che è stato esposto spetta al cliente: il fornitore non può cambiare la vostra chiave Stripe né quella di OpenAI.
Railway
Il 21 ottobre ha rilevato attività anomala nei sistemi che conservano le variabili d'ambiente dei clienti. Un terzo potrebbe aver avuto accesso a variabili cifrate e in alcuni casi averle decifrate. Ha sospeso i deploy e chiede di ruotare le credenziali. Non ha pubblicato né il numero di clienti coinvolti né il vettore. Fonte.
LiteLLM 1.107.0
Il 21 ottobre è stata pubblicata su PyPI e Docker Hub una 1.107.0 malevola: ruba credenziali e carica codice remoto all'avvio di qualsiasi processo Python. Gli attaccanti hanno usato token OAuth di GitHub CLI rubati a tre ingegneri; il tag su GitHub è pulito. È la seconda volta quest'anno. Fonte: Wiz.
PingCAP / TiDB Cloud
Tra il 9 settembre e il 7 ottobre un terzo ha usato credenziali rubate di un service account e ha copiato metadati di account e progetti, testo dell'editor SQL, registri di fatturazione e valori cifrati di API key. Nessuna prova di impatto sui dati archiviati in TiDB. Fonte: PingCAP.
Sei passaggi, dall'inventario ai token a vita breve
I primi quattro tolgono l'accesso e misurano il danno. Gli ultimi due cambiano il modo in cui conservate i segreti, così la prossima fuga tocca meno cose e dura meno.
- 01
Inventario dei segreti
Variabili del PaaS, file .env, segreti della CI, chiavi dentro le immagini Docker e nel codice. Per ognuno: a cosa dà accesso e in quanti punti si trova.
- 02
Ruotare in ordine
Fornitori di IA, cloud, database, gateway di pagamento e token di CI. Prima ciò che si trasforma più in fretta in consumi o in accesso ad altri segreti.
- 03
Revocare le vecchie
Una chiave che non usate più ma è ancora attiva vale lo stesso per chi la possiede. Verifichiamo presso ogni fornitore che la precedente sia revocata.
- 04
Controllare i log di utilizzo
Consumi dei fornitori di IA, CloudTrail o l'audit log del vostro cloud, accessi al database e la dashboard di Stripe, nella finestra di esposizione.
- 05
Secret manager
Spostiamo i segreti in un manager (quello del vostro cloud, Vault o Doppler) perché ognuno stia in un posto solo e ruotarlo sia cambiare un valore.
- 06
Token a vita breve
Dove il fornitore lo consente, la CI e i servizi chiedono credenziali temporanee (OIDC, ruoli IAM) invece di conservare chiavi che non scadono.
Cosa si ruota per primo e perché
LiteLLM è un proxy davanti ai fornitori di modelli, quindi una macchina che lo esegue di solito ha a portata di mano le chiavi di IA. Con una chiave di IA rubata qualcuno può generare consumi a vostre spese in pochi minuti, e una chiave cloud apre il resto.
I token di CI sono in fondo all'elenco perché li usiamo per fare il deploy delle modifiche precedenti. Se ci sono indizi che la CI stessa sia compromessa, passano in cima e nel frattempo facciamo il deploy da un'altra parte.
Creare, fare il deploy, revocare, verificare
Se si revoca prima di fare il deploy della nuova, l'applicazione si ferma. Se si fa il deploy della nuova senza revocare la vecchia, la fuga resta aperta.
Meno punti in cui vive ogni chiave
Ciò che richiede più tempo in una rotazione d'urgenza è scoprire dove si trova ogni chiave. Un secret manager trasforma quell'inventario in qualcosa che esiste già prima dell'incidente.
- La stessa API key sta sul PaaS, sul portatile di due persone e nella CI
- Nessuno sa quanti punti vanno toccati per ruotarla
- Le chiavi non scadono: una trapelata un anno fa funziona ancora
- Nessuna traccia di chi ha letto quale segreto e quando
- Ogni segreto sta in un posto (AWS Secrets Manager, Vault, Doppler o quello del vostro cloud) e le app lo leggono da lì
- Ruotare significa cambiare un valore e rifare il deploy
- La CI ottiene credenziali temporanee via OIDC invece di conservare chiavi fisse
- Il manager registra gli accessi, ed è la prima cosa da guardare in un incidente
Usate Railway, LiteLLM o TiDB Cloud?
Scrivici →Domande frequenti sulle credenziali esposte
Usiamo Railway: dobbiamo ruotare tutto?
Abbiamo LiteLLM 1.107.0: basta tornare alla 1.106.2?
Cosa dobbiamo fare se usiamo TiDB Cloud?
Perché quest'ordine?
Ruotare significa essere al sicuro?
Si parte dall'inventario
Dicci dove fate il deploy e quali fornitori usate. Con questo prepariamo l'elenco dei segreti da ruotare e l'ordine, e decidete se lo eseguiamo noi o il vostro team.
Raccontaci la tua sfida. Ti proponiamo la soluzione.
Senza impegno. In meno di 24 ore riceverai una proposta con ambito, tempistiche e budget. Nessuna clausola nascosta.