Red Hot Cyber
Sicurezza Informatica, Notizie su Cybercrime, Analisi Vulnerabilità e Intelligenza Artificiale
Persona con hoodie e maschera nera, seduta davanti a un laptop con interfaccia complessa, in un ambiente buio

Black Hacker dentro le infrastrutture AI! Il Cloud diventa la porta d’ingresso alle aziende

28 Agosto 2026 08:09
In sintesi

Le chiavi di accesso a Anthropic, OpenAI e Gemini sono state rubate da hacker che hanno violato l'infrastruttura IA delle aziende, secondo Microsoft. Gli esperti hanno rilevato attacchi su LiteLLM, RAGFlow e Kestra, dove i malintenzionati hanno rubato chiavi API, accesso a database e container, e avviato miner di criptovalute. La vulnerabilità CVE-2026-42271 ha permesso agli attaccanti di eseguire comandi tramite le interfacce di test del Model Context Protocol (MCP).

I servizi di intelligenza artificiale stanno diventando sempre più spesso non solo strumenti di lavoro, ma anche punti di accesso convenienti all’infrastruttura interna delle aziende. Gli esperti di Microsoft hanno rilevato attacchi reali su LiteLLM, RAGFlow e Kestra, dove i malintenzionati rubavano le chiavi dai modelli di IA, accedevano a database e container, si stabilivano sui server e avviavano miner di criptovalute.

Tutte e tre le piattaforme svolgono compiti diversi, ma occupano una posizione particolarmente vantaggiosa per gli attaccanti. LiteLLM funziona come gateway tra le applicazioni e i fornitori di modelli linguistici avanzati, RAGFlow elabora documenti e organizza la generazione con ricerca su dati esterni, mentre Kestra avvia processi di lavoro automatizzati.

Questi sistemi spesso hanno accesso diretto a chiavi API, database, servizi interni, configurazioni di container e risorse di calcolo. Se un componente viene compromesso, ciò apre molte più possibilità rispetto al crack di un normale sito web.

Advertising

La catena di attacco più complessa è stata rilevata in LiteLLM. Microsoft è altamente fiduciosa che gli attaccanti siano penetrati attraverso un gateway aperto su Internet. Il possibile percorso è legato alla vulnerabilità CVE-2026-42271 (8,8), che permetteva a un utente autorizzato di eseguire comandi tramite le interfacce di test del Model Context Protocol (MCP), e alla vulnerabilità CVE-2026-48710 (6,5) in Starlette. In determinate configurazioni, la combinazione di questi problemi permetteva di eseguire codice senza credenziali attive. CVE-2026-42271 (8,8) interessava LiteLLM dalla versione 1.74.2 alla 1.83.7, dove gli sviluppatori hanno risolto il problema.

Una volta entrati nel sistema, gli attaccanti hanno cercato immediatamente i segreti. Nei container dove LiteLLM funziona come processo con identificatore PID 1, il codice dannoso leggeva il file /proc/1/environ e cercava valori con parole come master, API key, token e password. Questi potevano contenere le chiavi dei fornitori di modelli di IA, la chiave principale di LiteLLM, l’indirizzo del database, le password dell’interfaccia e altri parametri sensibili. I dati raccolti venivano inviati all’esterno tramite Python, curl e wget, in modo che il malfunzionamento di uno strumento non fermasse il furto.

Successivamente, gli attaccanti caricavano file eseguibili ELF e mascheravano i processi come normali servizi di sistema Linux. I programmi dannosi verificavano i privilegi, le porte aperte, i miner attivi e gli strumenti di accesso remoto. Poi installavano XMRig o componenti simili per il mining di criptovalute, configuravano il processore per l’algoritmo RandomX e rimuovevano i miner concorrenti già presenti sul server.

Una stringa di connessione rubata a PostgreSQL ha permesso di passare dalla conquista del container ai dati stessi di LiteLLM. In un caso, il database funzionava su Azure Database for PostgreSQL. Gli attaccanti si sono connessi e hanno estratto tabelle con le impostazioni dei modelli e le chiavi proxy virtuali. Queste registrazioni possono contenere indirizzi dei fornitori di modelli, chiavi API e parametri di routing delle richieste. Per stabilirsi nel sistema, i malintenzionati aggiungevano una chiave SSH a authorized_keys, modificavano i compiti cron, nascondevano file nelle directory temporanee e assegnavano agli file dannosi l’attributo di immutabilità di Linux.

In RAGFlow lo scenario era diverso. Inizialmente, Microsoft ha notato azioni simili a una ricognizione tramite Server-Side Request Forgery (SSRF), dove l’applicazione stessa si collegava a un indirizzo specificato dagli attaccanti. Dopo alcuni giorni, nello stesso contesto è apparsa l’esecuzione di codice. Microsoft non è riuscita a identificare una specifica vulnerabilità, quindi non collega direttamente l’incidente a un errore noto di RAGFlow.

Advertising

Come possibile contesto tecnico, gli esperti hanno elencato diverse problematiche precedentemente riscontrate. Tra queste, l’iniezione di template lato server CVE-2026-45312 (9,9) nel generatore di richieste, una vulnerabilità simile CVE-2026-28797 (8,7) nei componenti Agent, un errore di bypass delle directory CVE-2026-24770 (9,8) in MinerU Parser, nonché CVE-2025-68700 (9,4) e CVE-2025-69286 (9,8).

La presenza di queste vulnerabilità da sola non dimostra che gli attaccanti ne abbiano sfruttata una nel caso rilevato.

Ottenuto l’accesso a RAGFlow, i malintenzionati hanno creato un modulo Python nascosto all’interno della directory dell’applicazione e modificato il meccanismo di avvio per caricare il codice dannoso insieme al servizio. L’obiettivo principale non erano le risorse di calcolo, ma nuove credenziali. Il modulo dannoso intercettava le impostazioni quando un utente aggiungeva o modificava una connessione a un modello linguistico avanzato. Nelle mani degli attaccanti finivano il nome del fornitore, il modello, la chiave API e l’indirizzo del servizio. Microsoft ha osservato questo meccanismo per le credenziali di OpenAI, Azure, Anthropic e Gemini.

Nel caso di Kestra, gli esperti collegano con alta fiducia l’accesso iniziale a una critica CVE-2026-49869 (10,0). L’errore nel filtro di autenticazione permetteva a un utente remoto senza password di creare e avviare i propri processi di lavoro. Poiché Kestra è in grado di eseguire script Shell, Python e altri, la vulnerabilità si trasformava effettivamente in un’esecuzione remota di comandi. Il problema interessava le versioni fino a 1.3.20 incluso, con gli sviluppatori che l’hanno corretta nelle versioni 1.0.45 e 1.3.21.


📢 Resta aggiornatoTi è piaciuto questo articolo? Rimani sempre informato seguendoci su 🔔 Google News.
Ne stiamo anche discutendo sui nostri social: 💼 LinkedIn, 📘 Facebook e 📸 Instagram.
Hai una notizia o un approfondimento da segnalarci? ✉️ Scrivici


Carolina Vivianti 300x300
Carolina Vivianti è consulente/Advisor autonomo in sicurezza informatica con esperienza nel settore tech e security. Ha lavorato come Security Advisor per Ford EU/Ford Motor Company e Vodafone e ha studi presso la Sapienza Università di Roma.
Aree di competenza: Cybersecurity, IT Risk Management, Security Advisory, Threat Analysis, Data Protection, Cloud Security, Compliance & Governance