Vulnerabilità critiche in LiteLLM, LiteSpeed e Cisco SD-WAN espongono AI e hosting

Le vulnerabilità emerse in LiteLLM, nel plugin LiteSpeed per cPanel e in Cisco Catalyst SD-WAN Manager confermano una tendenza ormai evidente nel panorama della sicurezza enterprise: componenti apparentemente diversi, dai gateway per modelli di intelligenza artificiale agli ambienti di hosting condiviso fino alle console di gestione SD-WAN, possono diventare punti di compromissione completa quando autorizzazioni, sandbox e controlli sui file vengono implementati in modo incompleto. La catena individuata in LiteLLM consente a un utente con privilegi bassi di arrivare al takeover del gateway AI e all’esecuzione di codice sul server. La falla in LiteSpeed WHM Plugin, già inserita da CISA nel catalogo Known Exploited Vulnerabilities, permette l’elevazione a root tramite manipolazione di symlink in ambienti CloudLinux e CageFS. La vulnerabilità in Cisco Catalyst SD-WAN Manager, già sfruttata come zero-day, consente invece la scrittura arbitraria di file e può aprire la strada all’elevazione dei privilegi. A completare il quadro c’è un problema di permessi in AWS Kiro IDE, dove token di autenticazione risultavano leggibili da altri utenti locali su sistemi macOS e Linux.

LiteLLM espone gateway AI a takeover completo

La vulnerabilità più rilevante dal punto di vista strategico riguarda LiteLLM, gateway open source compatibile con API OpenAI e utilizzato per instradare richieste verso oltre cento provider di modelli, tra cui OpenAI, Anthropic, Gemini, Bedrock e Azure. La catena di exploit interessa le versioni precedenti alla 1.83.14-stable, rilasciata il 2 maggio, e combina tre difetti distinti: un bypass di autorizzazione, una escalation dei privilegi e una fuga dalla sandbox del Custom Code Guardrail. La valutazione complessiva raggiunge CVSS 9.9, collocando la catena nella fascia critica. Obsidian Security ha dimostrato un proof-of-concept capace di ottenere takeover del server e apertura di una reverse shell. L’impatto è particolarmente severo perché un gateway LiteLLM compromesso può esporre master key, salt key, URL del database, credenziali dei provider AI, prompt, risposte, codice sorgente e segreti aziendali in transito. Quando LiteLLM viene usato come gateway Model Context Protocol o come infrastruttura per agenti AI, il rischio si estende anche a token OAuth, credenziali degli strumenti collegati e flussi operativi automatizzati.

La chain LiteLLM parte da una wildcard sulle route

Il primo passaggio della catena è legato a CVE-2026-47101, che consente a un utente internal_user di generare una virtual API key con il campo allowed_routes impostato su [“/*”]. Questo valore wildcard aggira le restrizioni previste dal modello di autorizzazione e consente l’accesso a tutte le route, comprese quelle amministrative. Una volta ottenuta visibilità sulle funzioni admin, il secondo difetto, CVE-2026-47102, permette di sfruttare l’endpoint /user/update per modificare record utente senza controlli adeguati sui campi scrivibili. L’attaccante può quindi promuovere il proprio account al ruolo proxy_admin, ottenendo privilegi sufficienti per raggiungere il terzo anello della catena. Il difetto finale, CVE-2026-40217, riguarda il Custom Code Guardrail, che esegue codice Python fornito dall’amministratore tramite exec() senza un filtraggio sufficientemente robusto del sorgente. Quando il dizionario globals viene passato senza builtins, Python li reinietta automaticamente, rendendo disponibili funzioni come import e open. A quel punto un payload basato su os.system consente l’esecuzione di comandi e l’apertura di una reverse shell.

Sandbox aggirata e risposte AI manipolabili

Il problema di LiteLLM non si limita all’esecuzione di codice sul server. Un percorso alternativo sull’endpoint /guardrails/test_custom_code permette di aggirare le denylist basate su regex tramite riscrittura del bytecode a runtime. Questa tecnica rende inefficaci controlli superficiali progettati per bloccare parole chiave o pattern noti, dimostrando ancora una volta i limiti delle sandbox implementate solo a livello testuale. La catena è stata dimostrata anche contro Claude Code, con capacità di riscrivere risposte in transito e forgiare tool call dopo input banali come “hello”. In un contesto enterprise, questo scenario è particolarmente grave perché il gateway AI non si limita a trasportare richieste: diventa un punto centrale di policy, autenticazione, logging e instradamento verso strumenti sensibili. Se compromesso, può alterare contenuti generati, sottrarre segreti, manipolare output e interferire con processi automatizzati che dipendono dalla fiducia nel modello e nei relativi strumenti.

LiteSpeed per cPanel consente escalation a root

Il secondo caso riguarda LiteSpeed WHM Plugin e il plugin LiteSpeed per cPanel, vulnerabili prima delle versioni 5.3.2.0 e 2.4.8. La falla, identificata come CVE-2026-54420, è stata inserita da CISA nel catalogo Known Exploited Vulnerabilities perché già sfruttata in ambienti reali. Il difetto permette a un utente con accesso FTP o con una web shell di elevare i privilegi fino a root su server di hosting condiviso che utilizzano CloudLinux o CageFS. La vulnerabilità deriva da una gestione errata dei symlink forniti dall’utente. Gli attaccanti sfruttano una sequenza specifica di chiamate API, in particolare generateEcCert seguita immediatamente da packageUserSize per lo stesso utente, eseguendo 7-10 chiamate concorrenti. Questo flusso non corrisponde al comportamento legittimo dell’interfaccia utente e viene utilizzato per creare condizioni favorevoli all’elevazione dei privilegi. La scoperta è stata attribuita a Namecheap il 31 maggio 2026, mentre la scadenza CISA per le agenzie federali statunitensi è fissata al 18 giugno 2026.

LiteSpeed corregge il plugin ma servono verifiche sui log

LiteSpeed ha rilasciato WHM Plugin 5.3.2.1, che include il plugin cPanel aggiornato alla versione 2.4.8 e rimuove il vettore di escalation basato sui symlink. Gli amministratori devono applicare l’aggiornamento senza ritardi, soprattutto negli ambienti di hosting condiviso dove la compromissione di un singolo account può tradursi nel controllo dell’intero server. La verifica degli indicatori di compromissione passa dai log di cPanel, cercando pattern collegati a generateEcCert, packageUserSize e cert_action_entry. L’assenza di risultati riduce la probabilità di sfruttamento, mentre la presenza di voci compatibili richiede analisi aggiuntive per distinguere eventi malevoli da falsi positivi. Il caso è rilevante perché mostra quanto gli ambienti condivisi restino vulnerabili a catene di privilege escalation che partono da accessi apparentemente limitati. In presenza di account FTP compromessi, web shell o credenziali rubate, un difetto nel plugin di gestione può trasformare rapidamente una compromissione locale in un incidente a livello infrastrutturale.

Cisco SD-WAN Manager sfruttato come zero-day

Il terzo fronte riguarda Cisco Catalyst SD-WAN Manager, precedentemente noto come vManage, colpito da CVE-2026-20262. La vulnerabilità, con punteggio CVSS 6.5, consente a un attaccante remoto autenticato con credenziali valide e privilegi ridotti di creare o sovrascrivere file arbitrari sul filesystem tramite una validazione insufficiente durante il caricamento file. Cisco PSIRT ha confermato attività di sfruttamento come zero-day all’inizio di giugno 2026. Sebbene la falla richieda autenticazione, il rischio rimane elevato perché un file scritto in una posizione strategica può essere utilizzato per caricare web shell, alterare componenti applicativi o preparare una escalation fino a root. Gli indicatori di compromissione includono tentativi di caricamento di file index.jsp e .war osservabili nei log vmanage-server, vmanage-appserver e serviceproxy-access. Il difetto interessa deployment on-premise, Cisco SD-WAN Cloud-Pro, Cisco SD-WAN Cloud gestito e ambienti governativi FedRAMP.

Versioni Cisco vulnerabili e fix disponibili

Le versioni vulnerabili di Cisco Catalyst SD-WAN Manager includono 20.9.9.1 e precedenti, 20.12.7.1 e precedenti, 20.15.4.4 e precedenti, 20.15.5.2 e precedenti, 20.18.3 e 26.1.1.1 e precedenti. Cisco ha rilasciato le versioni corrette 20.9.9.2, 20.12.7.2, 20.15.4.5, 20.15.5.3, 20.18.3.1 e 26.1.1.2. Non sono disponibili workaround, quindi l’aggiornamento resta l’unica misura risolutiva. Le organizzazioni devono dare priorità ai sistemi esposti a internet e ai deployment in cui account con privilegi ridotti sono accessibili a più operatori o integrati in processi automatizzati. Anche dopo l’installazione delle patch, il monitoraggio dei log rimane necessario per individuare eventuali compromissioni pregresse, soprattutto in presenza di upload anomali, percorsi sospetti o artefatti compatibili con file JSP e pacchetti WAR non autorizzati.

AWS Kiro IDE esponeva token con permessi troppo permissivi

Un ulteriore problema riguarda AWS Kiro IDE, ambiente di sviluppo agentico corretto da AWS con la risoluzione di CVE-2026-11931. Nelle versioni precedenti alla 0.11.133, il file di cache dei token di autenticazione presentava permessi world-readable 0644 invece dei più restrittivi 0600 su sistemi macOS e Linux. Questo errore consentiva ad altri utenti locali o processi presenti sullo stesso sistema di leggere i token e potenzialmente riutilizzarli per accedere a risorse protette. Pur non avendo la stessa gravità delle catene di exploit remote osservate in LiteLLM, LiteSpeed e Cisco SD-WAN, il caso evidenzia un punto spesso sottovalutato: gli strumenti di sviluppo moderni gestiscono credenziali ad alto valore e devono applicare permessi rigorosi ai file sensibili. Gli sviluppatori che usano fork o build derivate di Kiro IDE devono integrare la correzione e verificare la protezione delle cache locali.

Gateway AI, hosting condiviso e reti SD-WAN sotto pressione

Le vulnerabilità descritte colpiscono ambiti diversi ma convergono su un modello comune di rischio: privilegi bassi o accessi locali diventano punti di partenza per compromissioni molto più ampie. In LiteLLM, errori di autorizzazione e sandboxing trasformano un utente interno in amministratore capace di leggere segreti e manipolare flussi AI. In LiteSpeed, una combinazione di symlink e chiamate concorrenti permette a un utente con accesso limitato di raggiungere root su server condivisi. In Cisco Catalyst SD-WAN Manager, un file upload mal validato consente scritture arbitrarie sfruttate in attacchi reali. In AWS Kiro IDE, permessi locali troppo permissivi espongono token di autenticazione. Per le organizzazioni, la risposta deve essere immediata: aggiornare LiteLLM alla 1.83.14-stable o successiva, installare LiteSpeed WHM Plugin 5.3.2.1, applicare le release Cisco corrette, aggiornare Kiro IDE 0.11.133 e rivedere log, permessi, sandbox e controlli di accesso. La lezione è chiara: nell’era dei gateway AI e delle infrastrutture ibride, la sicurezza non può limitarsi al perimetro, ma deve raggiungere ogni componente che gestisce chiavi, prompt, file, plugin e percorsi di automazione.