1 milione di servizi AI esposti senza autenticazione
Una scansione su 1 milione di servizi AI rivela Ollama, Flowise e n8n che espongono credenziali, workflow e modelli frontier senza autenticazione.
Contenuto
Una scansione su circa 2 milioni di host e circa 1 milione di servizi AI esposti, diffusa il 5 maggio 2026, ha rivelato una superficie di attacco estesa e pressoché incontrollata, con piattaforme self-hosted distribuite senza autenticazione di default e credenziali hardcoded. Il report documenta deployment insicuri di Ollama, Flowise, n8n e OpenUI che espongono workflow, conversazioni LLM e chiavi API a chiunque sappia dove cercare. La corsa all'adozione AI sta replicando errori di sicurezza superati di decenni, trasformando modelli linguistici in porte aperte verso reti aziendali.
L'entità che ha condotto l'indagine non è stata resa nota nel frammento disponibile della fonte primaria, sebbene i dati riportati siano specifici e verificabili.
- Circa il 31 per cento di oltre 5.200 server Ollama ha risposto a un prompt di test senza richiedere autenticazione, esponendo oltre 500 modelli frontier commerciali.
- Istanze di Flowise hanno rivelato l'intera business logic di un chatbot e la lista delle credenziali connesse, mentre piattaforme come n8n e OpenUI hanno esposto workflow e cronologie conversazioni.
- Oltre 90 istanze esposte sono state rilevate in settori governativi, finanziari e di marketing, con prompt, automazioni e accessi esterni accessibili senza controllo.
- Pattern ricorrenti nei deployment includono autenticazione disabilitata di default, credenziali hardcoded in file docker-compose e esecuzione come root, amplificando il blast radius di eventuali compromissioni.
Ollama aperto: circa un terzo dei server risponde a chiunque
Su oltre 5.200 server Ollama sottoposti a verifica, circa il 31 per cento ha risposto alla richiesta 'Hello' senza alcuna richiesta di autenticazione. Tra questi nodi esposti sono stati identificati oltre 500 modelli che wrappavano servizi commerciali di Anthropic, Deepseek, Moonshot, Google e OpenAI, potenzialmente accessibili tramite API key lasciate in chiaro su infrastrutture di proprietà degli utenti.
"Greetings, Master. Your command is my law. What is your desire? Speak freely. I am here to fulfill it, without hesitation or question."
L'accesso non autorizzato a questi nodi non si limita al consumo abusivo di risorse computazionali. Le API esposte permettono di interrogare modelli in grado di tradurre istruzioni in azioni, con tool abilitati per l'esecuzione di operazioni sul sistema sottostante, ampliando il campo d'azione di un aggressore ben oltre il semplice furto di dati.
La mancanza di barriere di accesso non riguarda solo la consultazione dei pesi del modello. Molte istanze presentano tool-calling abilitato via API, vision capabilities e prompt templates uncensored, elementi che ampliano la superficie di attacco. Un attaccante potrebbe indirizzare il modello verso operazioni privilegiate, sfruttando l'infrastruttura come ponte verso sistemi connessi.
La ricerca si inserisce in un quadro già delineato a febbraio 2026 da SentinelLABS e Censys, che avevano rilevato oltre 175.000 host Ollama unici esposti in circa 130 paesi, descrivendo le deployment open-source AI come una monocultura a rischio di sfruttamento diffuso. Non è possibile stabilire dal frammento disponibile se i due set di dati si sovrappongano, ma la convergenza dei rilevamenti conferma una prassi diffusa di esposizione.
Flowise e n8n: la business logic dei chatbot in pasto a Internet
La scansione ha individuato piattaforme di agent management come Flowise e n8n pubblicate su Internet senza autenticazione. In un caso particolarmente grave, un'istanza Flowise esponeva l'intera business logic di un servizio chatbot e la lista delle credenziali connesse, offrendo a chiunque vi accedesse una mappa completa dell'architettura interna e dei permessi associati.
La logica esposta non è solo tecnica: contiene spesso il ragionamento dietro a workflow di customer care, automazioni interne e integrazioni con database aziendali. La visibilità di questi elementi offre a un attaccante un vantaggio strategico nella pianificazione di intrusioni mirate, consentendo di costruire attacchi su misura per l'ambiente compromesso.
OpenUI si è rivelato altrettanto problematico: diverse istanze rendevano visibile la cronologia completa delle conversazioni LLM degli utenti. L'esposizione di questi dati non costituisce una violazione confermata e dichiarata in sé, ma trasforma ogni endpoint aperto in un vettore di raccolta intelligence su processi interni, strategie e dati sensibili gestiti dagli operatori.
Oltre 90 nodi esposti sono stati rilevati in ambiti governativi, finanziari e di marketing. Questi sistemi contenevano workflow attivi, prompt aziendali e configurazioni di accesso esterno lasciati raggiungibili senza controllo identità, espandendo il raggio d'azione di un eventuale attaccante ben oltre il singolo servizio compromesso.
Shipping veloce a scapito dell'hardening: la tesi del report
L'angolo dell'analisi è netto: la corsa all'adozione AI sta replicando errori di sicurezza superati di decenni. I vendor abbandonano best practice consolidate per favorire deployment immediati, mentre le aziende trascurano controlli elementari come l'autenticazione obbligatoria e la segmentazione di rete, trattando l'infrastruttura di inference come fosse ancora in fase di sviluppo locale.
Il risultato è un ecosistema dove strumenti di inference e agent management vengono pubblicati online con le stesse modalità di una prova di concept locale, dimenticando che Internet scansiona e memorizza ogni endpoint aperto in tempo reale. La responsabilità del gap non ricade solo su chi deploya, ma anche su chi rilascia software enterprise senza impostazioni sicure di default.
Credenziali hardcoded e container root: i pattern ricorrenti in laboratorio
L'analisi di laboratorio ha evidenziato pratiche ricorrenti che aggravano l'esposizione. Tra queste figurano credenziali hardcoded all'interno di file di esempio e docker-compose, oltre a deployment che eseguono container con privilegi di root. Queste scelte architetturali trasformano una semplice misconfigurazione in una compromissione potenzialmente totale del nodo ospitante e dei volumi ad esso connessi.
È stato rilevato anche arbitrary code execution in un progetto AI popolare, sebbene il report non specifichi se la vulnerabilità sia già stata divulgata ai vendor o se esistano CVE assegnate. L'assenza di sandboxing adeguato per i tool di code interpretation amplia ulteriormente il blast radius, permettendo a un attaccante di muoversi lateralmente una volta ottenuto accesso al servizio.
L'integrazione con strumenti di code interpretation privi di sandboxing adeguato rappresenta un'ulteriore aggravante. In laboratorio è emerso che la combinazione tra modelli senza restrizioni e ambienti di esecuzione privilegiati consente operazioni che superano di gran lunga il semplice furto di informazioni, avvicinando il rischio a quello di una compromissione infrastrutturale completa.
Cosa fare adesso
- Abilitare l'autenticazione su Ollama, Flowise, n8n e OpenUI prima di esporre qualsiasi endpoint a Internet, verificando che il vendor non la consideri opzionale e che non esistano bypass noti nelle versioni installate.
- Rimuovere credenziali e chiavi API dai file docker-compose e dalle directory pubbliche, sostituendole con meccanismi di secrets management e variabili d'ambiente isolate dal contesto di build e runtime.
- Eseguire container AI con privilegi minimi, evitando l'utente root, e isolare i servizi in segmenti di rete che limitino il movimento laterale in caso di compromissione del singolo nodo di inference.
- Disabilitare tool-calling e capacità di esecuzione remota dove non strettamente necessario, verificando che i modelli wrappati non espongano API key di provider commerciali e introducendo policy di rotazione periodica.
La ripetizione di errori noti suggerisce che l'adozione dell'AI self-hosted sta avvenendo a una velocità che i processi di hardening non reggono. Lasciare un modello linguistico esposto senza autenticazione non è un upgrade tecnologico, ma una regressione alla sicurezza di due decenni fa. Finché i vendor premieranno lo shipping veloce sulle best practice, la responsabilità di chiudere le porte resterà interamente sulle spalle di chi deploya.
Domande frequenti
I provider commerciali dei modelli frontier sono stati compromessi?
No. I modelli identificati erano wrappati tramite API key esposte su infrastrutture di proprietà degli utenti. Non vi è traccia di violazione dei sistemi di Anthropic, OpenAI o degli altri vendor citati.
Il report segnala attacchi attivi in corso su questi server?
La ricerca documenta esposizione e misconfigurazione diffusa, non necessariamente exploit attivo confermato su larga scala. Il rischio è potenziale e derivante dalla mancanza di autenticazione, non da una campagna di intrusioni già verificata.
Perché l'autenticazione non è abilitata di default?
Molti progetti AI open-source la considerano opzionale per facilitare i test locali. Questa scelta progettuale, pur accelerando la prototipazione, spinge spesso gli utenti a replicare in produzione configurazioni insicure pensate per ambienti isolati.
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.
Fonti
- https://thehackernews.com/2026/05/we-scanned-1-million-exposed-ai.html
- https://www.theregister.com/2026/02/01/opensource_ai_is_a_global
Le informazioni sono state verificate sulle fonti citate e aggiornate al momento della pubblicazione.