Cyber-emergenza: CISA aggiorna il catalogo KEV, mentre LiteLLM crolla sotto un attacco SQL in sole 36 ore

La finestra temporale tra la scoperta di un bug e il suo sfruttamento si è ufficialmente azzerata. La CISA ha inserito nel catalogo KEV due falle critiche in Windows e ConnectWise già sfruttate da gruppi hacker russi e cinesi. Contemporaneamente, il proxy AI LiteLLM è finito nel mirino di un attacco SQL Injection massiccio (CVE-2026-42208), avvenuto appena 36 ore dopo la pubblicazione dell’advisory. Con la perdita potenziale di chiavi API di OpenAI e AWS Bedrock, le organizzazioni devono aggiornare i sistemi entro ore, non giorni, per evitare il compromesso totale degli account cloud.

CISA aggiunge due vulnerabilità attive al catalogo KEV

CISA pubblica il 28 aprile 2026 un nuovo aggiornamento del catalogo Known Exploited Vulnerabilities, inserendo due CVE sulla base di prove concrete di sfruttamento attivo. Il catalogo KEV resta uno strumento centrale per la prioritizzazione delle remediation, perché identifica vulnerabilità già usate dagli attaccanti in campagne reali. Le organizzazioni federali americane devono applicare le patch entro il 12 maggio 2026 in conformità al Binding Operational Directive 22-01. L’aggiornamento riguarda la CVE-2024-1708 in ConnectWise ScreenConnect e la CVE-2026-32202 in Microsoft Windows Shell.

• CVE-2024-1708 ConnectWise ScreenConnect Path Traversal Vulnerability
• CVE-2026-32202 Microsoft Windows Protection Mechanism Failure Vulnerability

CISA invita anche le organizzazioni private a integrare il catalogo KEV nei processi quotidiani di vulnerability management. Il messaggio è chiaro: quando una vulnerabilità entra nel catalogo, non rappresenta più un rischio teorico ma un vettore operativo già osservato sul campo.

CVE-2024-1708 colpisce ConnectWise ScreenConnect con path traversal

La CVE-2024-1708 è una vulnerabilità di path traversal in ConnectWise ScreenConnect con punteggio CVSS 8.4. La falla può consentire accesso a dati sensibili, compromissione di sistemi critici ed esecuzione di codice remoto in scenari di attacco concatenati. ConnectWise ha corretto il problema già a febbraio 2024, ma molte installazioni esposte continuano a rappresentare un rischio concreto. Gli attacchi osservati combinano spesso la CVE-2024-1708 con la CVE-2024-1709, bypass di autenticazione critica già sfruttata in campagne ransomware. Microsoft ha collegato alcune attività al gruppo Storm-1175, che avrebbe usato le vulnerabilità per distribuire Medusa ransomware. La presenza nel catalogo KEV impone una verifica immediata di tutte le istanze ScreenConnect, soprattutto negli ambienti di remote access ancora non aggiornati.

Microsoft Windows Shell espone sistemi a spoofing di rete

La CVE-2026-32202 riguarda un fallimento del meccanismo di protezione in Microsoft Windows Shell con punteggio CVSS 4.3. La vulnerabilità consente spoofing di rete da parte di un attaccante non autorizzato e deriva da una correzione incompleta della CVE-2026-21510. Microsoft aggiorna l’advisory il 27 aprile 2026 riconoscendo lo sfruttamento attivo. La falla viene collegata ad attività del gruppo russo APT28, già associato allo sfruttamento di vulnerabilità Windows come zero-day contro Ucraina e paesi dell’Unione Europea dal dicembre 2025. Gli attaccanti usano la CVE-2026-32202 insieme alla CVE-2026-21513 per operazioni mirate. Anche se il punteggio CVSS non è elevatissimo, lo sfruttamento attivo rende l’aggiornamento di aprile 2026 prioritario per ridurre rischi di spoofing, furto credenziali e movimento laterale.

LiteLLM introduce una SQL injection critica pre-auth

In parallelo all’aggiornamento KEV, emerge la CVE-2026-42208, una SQL injection critica in LiteLLM con punteggio CVSS 9.3. La vulnerabilità colpisce le versioni del pacchetto Python comprese tra 1.81.16 e 1.83.7 e permette a un attaccante non autenticato di inviare un header Authorization Bearer appositamente costruito verso route LLM API come POST /chat/completions. Il problema nasce dalla concatenazione diretta del valore fornito dall’utente in una query SQL, invece dell’uso di parametri sicuri. Questo consente di raggiungere il percorso di gestione degli errori del proxy ed eseguire query arbitrarie sul database PostgreSQL sottostante. LiteLLM rilascia la versione corretta 1.83.7-stable il 19 aprile 2026, sostituendo l’interpolazione di stringhe con query parametrizzate.

Attacco LiteLLM sfrutta la verifica API key prima dell’autenticazione

La vulnerabilità si trova nella fase di verifica delle chiavi API del proxy LiteLLM, prima che l’autenticazione protegga davvero la richiesta. Il valore del token Bearer viene concatenato nella tabella LiteLLM_VerificationToken senza sanitizzazione adeguata. Un payload costruito con UNION SELECT può permettere di enumerare colonne, leggere tabelle e raggiungere dati sensibili presenti nel database. Gli attaccanti mirano a tabelle come litellm_credentials, litellm_config e LiteLLM_VerificationToken. La mancanza di rate limiting, allow list IP o controlli forti sul percorso di autenticazione rende l’exploit eseguibile da qualsiasi client HTTP che raggiunga la porta del proxy. L’attività osservata usa user-agent come Python/3.12 aiohttp/3.9.1 e IP adiacenti, segnale di un operatore che conosce bene lo schema Prisma usato da LiteLLM.

Exploit LiteLLM arriva 36 ore dopo la disclosure pubblica

L’advisory GHSA-r75f-5x8p-qvmc viene pubblicato il 20 aprile 2026 e indicizzato nel database globale GitHub il 24 aprile 2026 alle 16:17 UTC. Il primo tentativo di SQL injection viene registrato il 26 aprile 2026 alle 04:24 UTC, appena 36 ore e sette minuti dopo la disclosure. La velocità conferma quanto rapidamente gli attaccanti monitorino advisory pubbliche e repository open source. L’attività si sviluppa in due fasi, con IP 65.111.27.132 e 65.111.25.67 appartenenti allo stesso ASN. Gli aggressori eseguono 17 payload UNION, enumerano il numero di colonne con placeholder NULL e sondano endpoint come /key/generate e /key/info senza autenticazione. Sysdig sottolinea che l’operatore non ha atteso un proof-of-concept pubblico, ma ha costruito l’exploit partendo dall’advisory e dallo schema open source.

Credential OpenAI Anthropic e AWS Bedrock diventano esposte

L’impatto della CVE-2026-42208 è particolarmente grave perché LiteLLM centralizza credenziali di provider LLM in un unico proxy. La tabella litellm_credentials.credential_values può contenere chiavi OpenAI con limiti di spesa elevati, chiavi Anthropic con privilegi amministrativi workspace e credential IAM AWS Bedrock. La tabella litellm_config può includere variabili d’ambiente, DSN PostgreSQL, master key e URL di callback. Un’estrazione riuscita equivale a un compromesso molto più ampio di una normale SQL injection web. Gli attaccanti possono riutilizzare chiavi upstream, generare traffico AI non autorizzato, accedere a modelli, creare costi cloud e compromettere account collegati. Il blast radius supera il singolo server LiteLLM perché coinvolge provider esterni, ambienti cloud e credenziali operative spesso usate in produzione.

Amministratori LiteLLM devono aggiornare e ruotare tutte le chiavi

Gli amministratori devono aggiornare immediatamente LiteLLM alla versione 1.83.7 o successiva. Chi non può applicare subito la patch deve impostare disable_error_logs: true nella sezione general_settings per bloccare il percorso vulnerabile. Sysdig consiglia anche di posizionare il proxy dietro un reverse proxy capace di filtrare header Authorization contenenti apici, parentesi o keyword SQL come UNION, SELECT, FROM, OR e —. Le organizzazioni devono trattare ogni istanza internet-facing vulnerabile come potenzialmente compromessa. Tutte le virtual API key, le master key e le credenziali dei provider upstream devono essere ruotate. È necessario controllare log di billing e consumo su OpenAI, Anthropic, AWS Bedrock e altri provider collegati, cercando traffico anomalo. Le istanze LiteLLM dovrebbero essere esposte solo su reti interne, VPN o ambienti con autenticazione reciproca.

LiteLLM mostra la nuova superficie d’attacco delle infrastrutture AI

LiteLLM conta oltre 45.000 stelle su GitHub e funziona come gateway verso decine di provider LLM. La sua diffusione lo rende un bersaglio naturale per attaccanti interessati a credential AI, costi cloud e accesso a modelli proprietari. Il caso conferma che i proxy AI non sono semplici componenti ausiliari, ma infrastrutture critiche che concentrano chiavi, policy, limiti di spesa e log di utilizzo. L’incidente segue un pattern ormai evidente: software open source molto adottato, vulnerabilità pre-auth, impatto elevato e sfruttamento in tempi rapidissimi. Le organizzazioni devono quindi applicare alle infrastrutture AI gli stessi standard usati per sistemi enterprise esposti. Inventory, patching rapido, secret management, logging e segmentazione diventano requisiti minimi. Ogni advisory AI deve essere trattata come emergenza operativa, non come aggiornamento ordinario.

CISA KEV e LiteLLM mostrano vulnerabilità vecchie e nuove sotto attacco

Le due CVE aggiunte da CISA colpiscono prodotti enterprise consolidati come ConnectWise ScreenConnect e Microsoft Windows, mentre la CVE-2026-42208 riguarda un tool open source emergente nel settore AI. La differenza è significativa ma il problema è comune: gli attaccanti sfruttano rapidamente qualunque superficie offra accesso, credenziali o movimento laterale. Le vulnerabilità storiche non patchate convivono con falle nuove in infrastrutture moderne. Nel caso ScreenConnect, il rischio deriva da sistemi di remote access esposti e già abusati in campagne ransomware. Nel caso Windows Shell, da una patch incompleta e da operazioni mirate legate ad APT. Nel caso LiteLLM, da un proxy AI che concentra chiavi ad alto valore e viene sfruttato appena dopo la disclosure. Le aziende devono gestire entrambe le dimensioni: legacy enterprise e nuovi stack AI.

Vulnerability management deve accelerare da giorni a ore

La sequenza degli eventi mostra che i tempi tradizionali di remediation non sono più sufficienti. LiteLLM viene attaccato in 36 ore, mentre vulnerabilità già corrette da mesi o anni continuano a entrare nel catalogo KEV perché restano sfruttabili in ambienti non aggiornati. Le organizzazioni devono ridurre il tempo tra advisory, triage e patching, soprattutto quando un componente è esposto a internet o contiene credenziali sensibili. Un programma moderno di vulnerability management deve includere inventory continua, classificazione per esposizione reale, patch automatizzate dove possibile, secret rotation e threat hunting post-patch. Per i proxy AI, la priorità deve considerare anche i limiti di spesa associati alle chiavi e i privilegi cloud collegati. La domanda non è più solo quale CVE abbia il punteggio più alto, ma quale vulnerabilità possa produrre il blast radius più ampio in meno tempo.

Patch tempestive e monitoraggio continuo diventano indispensabili

Il nuovo aggiornamento CISA KEV e l’exploit contro LiteLLM indicano una stessa direzione: patch rapide, monitoraggio continuo e protezione delle credenziali devono diventare processi ordinari. Le organizzazioni federali devono chiudere le due vulnerabilità KEV entro il 12 maggio 2026, ma anche le aziende private dovrebbero usare la stessa urgenza. Per LiteLLM, l’aggiornamento alla 1.83.7 e la rotazione delle chiavi non sono facoltativi. Il settore AI aggiunge una superficie d’attacco nuova, dove un singolo proxy può contenere accessi a più provider e generare costi immediati. Gli attaccanti lo hanno capito e monitorano disclosure pubbliche con automazione crescente. Le aziende devono reagire con la stessa velocità, trattando advisory, log di autenticazione e anomalie di billing come segnali operativi critici. La sicurezza non dipende più solo dal patching, ma dalla capacità di vedere e contenere lo sfruttamento nelle prime ore.