Exploit LiteLLM in 36 ore: SQL injection pre-auth sfruttata sulle chiavi AI

Exploit LiteLLM in 36 ore: SQL injection pre-auth sfruttata sulle chiavi AI Il 26 aprile 2026, alle 04:24 UTC, un attaccante ha iniziato a sfruttare attivamente la vulnerabilità SQL injection pre-autenticazione CVE-2026-42208 in BerriAI LiteLLM. L'evento si è verificato solo 36 ore e 7 minuti dopo l'indicizzazione pubblica dell'advisory nel GitHub Advisory Database globale, avvenuto il 24 aprile alle 16:17 UTC.

L'attacco mirato all'estrazione di chiavi API LLM ad alto valore dimostra come la disponibilità dello schema del database open-source abbia permesso l'exploit senza la necessità di una Proof of Concept pubblica. Questa rapidità segnala una vulnerabilità critica per chi gestisce infrastrutture AI esposte su reti pubbliche.

Meccanica della CVE-2026-42208

La vulnerabilità, classificata con un punteggio CVSS 9.3, risiede nel flusso di autenticazione del gateway, progettato per validare e gestire l'accesso ai servizi di intelligenza artificiale. L'input dell'utente nell'header Authorization viene concatenato direttamente in una query SQL per il controllo delle chiavi API, senza alcuna parametrizzazione o sanitizzazione dei dati in ingresso.

Questa architettura difettosa permette l'esecuzione di un attacco UNION-based SQL injection pre-autenticazione. Quando l'applicazione riceve una chiave API non valida, il flusso di esecuzione devia verso un path di gestione degli errori che esegue la query avvelenata direttamente contro il database PostgreSQL sottostante, esponendo i dati.

Poiché la vulnerabilità non richiede credenziali valide per essere innescata, qualsiasi istanza esposta a Internet è suscettibile all'esplorazione non autenticata del database. L'assenza di controlli rende questo difetto critico per le infrastrutture cloud che espongono il gateway senza restrizioni di rete adeguate.

L'attaccante può sfruttare questa falla per estrarre intere tabelle o manipolare i dati memorizzati. La mancanza di preparazione delle dichiarazioni SQL nel path di errore rappresenta un errore architetturale grave in un componente che gestisce segreti ad alto valore, come le chiavi di accesso ai modelli AI.

Dinamica e tempistiche dell'exploit

L'advisory originale è stato indicizzato nel GitHub Advisory Database globale il 24 aprile 2026 alle 16:17 UTC. Gli analisti di Sysdig hanno rilevato il primo traffico malevolo proveniente dagli IP 65.111.27.132 e 65.111.25.67 esattamente 36 ore e 7 minuti dopo, il 26 aprile alle 04:24 UTC.

L'operatore non ha atteso il rilascio di tool automatizzati o script pubblici per avviare l'attacco. La trasparenza dell'ecosistema open-source ha fornito la mappa necessaria per costruire le query. Come sottolineato dal team di ricerca Sysdig: "The advisory and the open-source schema were ultimately enough."

L'attacco non ha assunto la forma di una scansione di massa generica tramite strumenti automatizzati. L'operatore ha condotto un'enumerazione mirata del conteggio delle colonne, inviando 17 payload UNION SELECT contro tre tabelle specifiche che ospitano chiavi LLM e configurazioni di sistema.

Questa precisione rivela una conoscenza pregressa del framework Prisma utilizzato da LiteLLM per l'ORM. L'obiettivo dell'attaccante era chiaramente la mappatura dei segreti ad alto valore, isolando le righe di dati critiche senza esplorare tabelle di sistema irrilevanti per l'accesso alle credenziali.

"The novelty of this finding is the speed and precision of the schema-enumeration attempt, not a confirmed compromise." - Sysdig Threat Research Team

Impatto potenziale sull'infrastruttura cloud

Un gateway AI come LiteLLM agisce da punto di raccolta per credenziali cloud dal valore molto elevato. Il rischio associato a questa vulnerabilità supera nettamente quello di una tipica SQL injection in un'applicazione web standard, poiché un singolo database può centralizzare l'accesso a molteplici provider di servizi AI.

Una singola riga compromessa nella tabella litellm_credentials può contenere un concentrato di accesso critico. Al suo interno possono essere presenti chiavi organizzative OpenAI, chiavi console Anthropic e credenziali AWS Bedrock IAM. Lo spending limit associato a queste chiavi può facilmente raggiungere cifre a cinque cifre mensili.

L'estrazione del database si traduce direttamente in una compromissione dell'account cloud sottostante. Un attaccante potrebbe utilizzare le chiavi rubate per generare contenuti, accedere a modelli proprietari o scalare l'attacco verso altre risorse AWS sfruttando le credenziali IAM esposte nel gateway.

Come evidenziato da Sysdig: "The blast radius of a successful database extraction is closer to a cloud-account compromise than a typical web-app SQL injection." Sebbene non sia stato registrato un follow-through, le condizioni per una compromissione totale erano interamente soddisfatte.

Non è stata rilevata esfiltrazione di dati, generazione di chiavi virtuali o riuso delle credenziali, ma il rischio residuo per le istanze non patchate rimane critico. La centralizzazione delle chiavi API amplifica in modo significativo la superficie d'attacco dell'intero ecosistema cloud aziendale.

Cosa fare adesso

• Aggiornare immediatamente tutte le istanze BerriAI LiteLLM alla versione 1.83.7, che corregge la vulnerabilità ed è stata rilasciata il 19 aprile 2026. I sistemi in esecuzione sulle versioni 1.81.16 - 1.83.6 sono vulnerabili e devono essere isolati se non aggiornabili.
• Ispezionare i log di PostgreSQL e del gateway per rilevare i 17 payload UNION SELECT specifici o qualsiasi query anomala sulle tabelle delle credenziali risalente al 26 aprile 2026, verificando l'assenza di accessi dagli IP 65.111.27.132 e 65.111.25.67.
• Ruotare e rigenerare d'urgenza tutte le chiavi API LLM (OpenAI, Anthropic, AWS Bedrock) transitanti per il gateway, anche in assenza di conferme di esfiltrazione o follow-through da parte dell'attaccante, revocando quelle precedenti.
• Limitare strettamente l'accesso di rete alle interfacce di gestione del gateway, impedendo l'esposizione diretta su Internet, e monitorare il traffico in uscita verso gli IP associati all'enumerazione mirata documentata da Sysdig.

L'episodio di LiteLLM evidenzia un aspetto critico per la sicurezza dell'infrastruttura AI: la convergenza tra disclosure pubblica, archivi open-source e tempistiche di attacco ridotte a poche decine di ore. Le organizzazioni non possono gestire le vulnerabilità secondo i cicli di update tradizionali.

Quando la conoscenza dello schema interno diventa pubblica, l'attacco mirato diventa immediato. Ritardare l'aggiornamento espone l'infrastruttura a gravi compromissioni dell'account cloud aziendale. La velocità di risposta è ora il fattore determinante per la sicurezza delle piattaforme di gestione delle AI.

FAQ

• Cos'è la CVE-2026-42208? Una vulnerabilità SQL injection pre-autenticazione (CVSS 9.3) in BerriAI LiteLLM che permette a un attaccante non autenticato di eseguire query arbitrarie sul database PostgreSQL sfruttando l'header Authorization.
• Quali versioni di LiteLLM sono vulnerabili? Le versioni da 1.81.16 a 1.83.6 sono affette dalla vulnerabilità. La versione 1.83.7 corregge il difetto ed è stata rilasciata il 19 aprile 2026.
• C'è stata una violazione confermata dei dati? No. Gli analisti hanno osservato solo l'enumerazione mirata dello schema del database, senza rilevare esfiltrazione di dati, generazione di chiavi virtuali o riuso delle credenziali da parte dell'attaccante.

Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.

Fonti

• https://thehackernews.com/2026/04/litellm-cve-2026-42208-sql-injection.html
• https://www.sysdig.com/blog/cve-2026-42208-targeted-sql-injection-against-litellms-authentication-path-discovered-36-hours-following-vulnerability-disclosure
• https://securityaffairs.com/191483/hacking/cve-2026-42208-litellm-bug-exploited-36-hours-after-its-disclosure.html