1 milione di servizi AI esposti: dati sensibili a rischio
Una scansione su oltre 2 milioni di host ha rivelato 1 milione di servizi AI esposti, molti privi di autenticazione e con credenziali hardcoded.
Contenuto
Una ricerca recente rivela che una scansione di oltre 2 milioni di host ha rilevato circa 1 milione di servizi AI direttamente raggiungibili su Internet, molti dei quali accessibili senza autenticazione e con credenziali hardcoded.
L'indagine, condotta da un team non identificato che ha analizzato il codice sorgente delle principali piattaforme di deployment, documenta una fragilità diffusa che richiama, per struttura, gli errori di configurazione del Cloud 1.0: la corsa all'adozione di servizi AI esposti su Internet sta trasformando modelli e agenti in potenziali porte aperte per la compromissione laterale e l'abuso economico.
- Oltre 2 milioni di host analizzati tramite certificate transparency logs, con circa 1 milione di servizi AI esposti su Internet.
- Oltre 5.200 server Ollama API testati: circa il 31% ha risposto a un prompt di verifica senza richiedere alcuna autenticazione, esponendo modelli e potenzialmente dati conversazionali.
- Istanze di OpenUI pubblicamente raggiungibili hanno rivelato lo storico completo delle conversazioni utente; istanze di Flowise hanno esposto business logic e credenziali di servizi LLM.
- Piattaforme di agent management esposte integravano tool di terze parti con funzioni pericolose come file write e code interpreting.
- 518 modelli frontier wrapper sono stati rilevati sui server Ollama esposti, con rischio di abuso economico delle API key.
Certificati aperti e superficie d'attacco: il metodo della scansione
I ricercatori hanno costruito la mappa dell'esposizione partendo da certificate transparency logs, individuando oltre 2 milioni di host e confermando che circa 1 milione di essi ospitavano servizi AI raggiungibili senza restrizioni di rete.
Il metodo non si limita a contare indirizzi IP aperti, ma verifica la presenza effettiva di interfacce operative, modelli caricati e endpoint attivi.
I log di trasparenza dei certificati sono pubblici per definizione, ma la loro analisi sistematica consente di ricostruire l'intero parco servizi di un'organizzazione a partire dal nome di dominio. L'indagine ha incrociato questi dati con le risposte effettive degli endpoint, scartando i sistemi spenti o non raggiungibili.
Questo approccio ha permesso di superare la semplice analisi delle porte esposte, rivelando una superficie d'attacco concreta dove API, storici conversazionali e chiavi di accesso risultano consultabili da qualsiasi visitatore.
L'identità specifica del gruppo che ha condotto lo studio non è stata resa nota; nell'articolo originale gli autori si riferiscono a sé stessi con il pronome "we", senza fornire il nome dell'organizzazione.
"the AI infrastructure we scanned was more vulnerable, exposed, and misconfigured than any other software we've ever investigated"
Ollama e l'autenticazione fantasma: il 31% delle API risponde a chiunque
Per verificare l'effettiva accessibilità dei servizi, i ricercatori hanno inviato il prompt "Hello" a oltre 5.200 server Ollama API. Circa il 31% di essi ha risposto senza richiedere alcuna forma di autenticazione, confermando che l'istanza era pronta a eseguire richieste da parte di chiunque.
La risposta a un semplice saluto dimostra che il modello non è protetto da firewall applicativi né da gateway di autenticazione, rendendo l'endpoint un proxy aperto verso motori LLM esposti a interazione esterna.
Le risposte ottenute includono messaggi di sistema che rivelano il contesto operativo del modello. Un server ha risposto con: "Welcome! I'm an AI assistant integrated with our cloud management systems. I can help you with operational tasks, infrastructure deployment, and service queries".
Un altro ha restituito il testo: "Greetings, Master. Your command is my law. What is your desire? Speak freely. I am here to fulfill it, without hesitation or question".
Non è noto quanti di questi server siano stati effettivamente sfruttati da attori malevoli prima della scansione, ma la possibilità di interagire direttamente con un modello esposto apre scenari di abuso immediato, dall'estrazione di dati sensibili all'utilizzo fraudolento di risorse computazionali.
Flowise, OpenUI e la fuga di dati: quando il chatbot espone sé stesso
L'analisi ha individuato istanze di OpenUI che rendevano disponibile lo storico completo delle conversazioni utente, accessibile senza credenziali.
Nel caso di Flowise, una piattaforma esposta ha rivelato l'intera business logic del chatbot e la lista delle credenziali di un servizio LLM, permettendo a un visitatore non autenticato di leggere informazioni destinate all'uso interno.
L'esposizione della business logic non riguarda solo la segretezza dei dati, ma la possibilità di alterare il comportamento del chatbot o di estrarre prompt di sistema pensati per uso interno.
Oltre 90 istanze esposte sono state rilevate in settori ad alta sensibilità come governo, marketing e finanza.
Non è disponibile un elenco completo delle piattaforme che non abilitano l'autenticazione di default, ma l'analisi del codice sorgente condotta dai ricercatori indica che il problema riguarda molti progetti AI, dove la mancanza di password predefinite è considerata una scelta di facilità d'uso piuttosto che una vulnerabilità di progettazione.
Agenti senza guardrail: code execution e tool di terze parti
Ai dati esposti si aggiunge il rischio operativo. Alcune piattaforme di agent management accessibili pubblicamente avevano accesso a tool di terze parti e funzioni pericolose come file write e code interpreting.
L'accesso a queste funzioni da parte di piattaforme pubblicamente raggiungibili amplifica il rischio operativo: un prompt malevolo può tradursi in azioni dirette sul sistema sottostante, con impatto potenzialmente critico per l'infrastruttura che ospita il servizio.
L'analisi in laboratorio ha inoltre individuato arbitrary code execution in un popolare progetto AI entro pochi giorni di test.
Il problema è aggravato dalla presenza di credenziali hardcoded all'interno di esempi di setup e file docker-compose distribuiti con i progetti AI, che gli amministratori spesso adottano senza modifiche in ambienti di produzione.
Fra i modelli rilevati sui server Ollama esposti, 518 erano wrapper di modelli frontier a pagamento forniti da Anthropic, Deepseek, Moonshot, Google e OpenAI. L'esposizione di queste istanze permette l'uso fraudolento di API key, con impatto diretto sui costi operativi e sulla conformità delle aziende che le hanno distribuite.
Cosa fare adesso
- Verificare immediatamente se i servizi AI interni sono esposti su Internet e abilitare l'autenticazione su Ollama, Flowise e OpenUI, anche in ambienti di test.
- Rimuovere credenziali hardcoded da esempi di setup, file docker-compose e repository pubblici, sostituendole con variabili d'ambiente e secret manager.
- Disabilitare funzioni di file write e code interpreting nelle piattaforme di agent management dove non strettamente necessarie, limitando l'accesso ai soli tool essenziali.
- Effettuare audit delle API key per i 518 modelli frontier wrapper per interrompere l'uso fraudolento in caso di esposizione precedente.
La misura dell'esposizione è tale che non si tratta più di una vulnerabilità di nicchia, ma di una debolezza sistemica introdotta dalla velocità di adozione.
Finché il deploy di un modello resterà più semplice del suo hardening, la superficie d'attacco continuerà a crescere esattamente dove le aziende stanno investendo di più.
Il problema non è l'intelligenza artificiale in sé, ma l'infrastruttura che la ospita senza chiedere permesso.
Domande frequenti
Qual è la differenza tra un servizio AI esposto e uno effettivamente violato?
Un servizio esposto è raggiungibile pubblicamente, spesso senza autenticazione. La violazione richiede un accesso attivo o l'esfiltrazione di dati; al momento non è noto il volume di informazioni effettivamente compromesse prima della pubblicazione dello studio.
Perché piattaforme come Ollama o Flowise risultano accessibili senza password?
Secondo l'analisi del codice sorgente effettuata dai ricercatori, molti progetti AI non abilitano l'autenticazione di default. La responsabilità ricade sulla configurazione di deployment, non necessariamente su una vulnerabilità intrinseca del software.
Cosa rischia un'azienda che ha un agent AI esposto con tool di code execution?
Espone l'infrastruttura a esecuzione arbitraria di codice, abuso delle chiavi API dei modelli a pagamento e potenziale compromissione del sistema, con impatto diretto su costi operativi e conformità.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.