36.769 servizi di IA esposti su Internet

L’accessibilità pubblica interessa l’intera filiera dell’IA

Uno studio pubblicato l’11 settembre ha individuato 36.769 endpoint di IA pubblicamente raggiungibili, dai server per modelli locali alle piattaforme di automazione e alle console per vector store.

I ricercatori di Mysterium VPN hanno individuato i sistemi interrogando l’indice di scansione Internet di Netlas e confrontando le impronte specifiche dei servizi. Solo il 2,02% degli endpoint identificati ha restituito una risposta HTTP 401 o 403, i codici di stato utilizzati come prova della presenza di una barriera di autenticazione.

Questo non significa che tutti gli altri servizi consentissero un accesso senza restrizioni. Le pagine di login possono restituire HTTP 200, mentre l’autenticazione può essere applicata altrove nell’applicazione. Il dato mostra invece che la maggior parte delle installazioni non presentava una sfida rilevabile a livello di rete sull’endpoint sottoposto a scansione.

La ricerca ha misurato l’esposizione osservabile, non l’avvenuta intrusione. I ricercatori non hanno recuperato documenti, esaminato cronologie delle chat, letto credenziali, eseguito modelli, sfruttato vulnerabilità né pubblicato nomi host e indirizzi IP.

Il totale rappresenta inoltre una stima per difetto. Gli indici di scansione Internet non coprono ogni porta o host e le impronte rigorose escludono i sistemi che non possono essere attribuiti con sufficiente certezza a un prodotto specifico.

La distribuzione mostra comunque come l’infrastruttura di IA autogestita possa esporre diversi asset distinti: capacità GPU, credenziali dei flussi di lavoro, connessioni ai sistemi aziendali e dati privati utilizzati per la generazione aumentata dal recupero.

I server per modelli rappresentano la maggior parte dei sistemi esposti

Open WebUI era il prodotto più numeroso nel dataset, con 18.529 istanze raggiungibili. Solo una ha restituito una richiesta di autenticazione HTTP.

I ricercatori hanno inoltre identificato:

• 4.880 endpoint vLLM, tre dei quali hanno restituito una richiesta di autenticazione;
• 150 endpoint LocalAI, nessuno dei quali ha restituito una richiesta di autenticazione;
• 69 endpoint llama.cpp, nessuno dei quali ha restituito una richiesta di autenticazione.

Questi numeri non dimostrano che ogni installazione fosse utilizzabile in forma anonima. Un’interfaccia di login di Open WebUI, per esempio, può rispondere con HTTP 200 pur richiedendo credenziali prima di esporre conversazioni o funzioni dei modelli.

Ollama ha fornito prove più solide, perché il suo endpoint principale presenta il testo riconoscibile Ollama is running senza richiedere l’autenticazione. Mysterium ha rilevato 6.935 host con questa impronta, inclusi 6.046 che hanno risposto esplicitamente con HTTP 200.

Un’API Ollama esposta può rivelare i modelli installati e consentire a un utente esterno di inviare richieste di inferenza utilizzando l’hardware dell’operatore. Gli aggressori possono quindi consumare tempo GPU ed elettricità senza compromettere l’host nel senso tradizionale del termine.

Questo abuso delle risorse è comunemente descritto come LLMjacking. Può generare costi, degradare il servizio per gli utenti legittimi e associare l’infrastruttura dell’operatore a contenuti generati da una terza parte sconosciuta.

Un’analisi separata di SentinelOne e Censys, pubblicata a gennaio, ha contato circa 175.000 host Ollama esposti in 130 Paesi. Quasi la metà supportava funzionalità di esecuzione di strumenti in grado di eseguire codice, invocare API o comunicare con sistemi esterni. Le differenze nella copertura della scansione e nei requisiti delle impronte spiegano perché quel totale fosse nettamente più elevato.

Mysterium ha inoltre osservato 22.024 risposte sulla porta predefinita di Ollama, 11434. Questi sistemi sono stati esclusi dal conteggio principale perché la presenza di una porta, da sola, non dimostra quale applicazione sia in ascolto. Di queste risposte, 4.136, pari al 18,8%, provenivano dagli Stati Uniti.

I ricercatori hanno tentato una suddivisione più ampia per Paese, ma l’hanno scartata dopo che i limiti di frequenza hanno reso inaffidabili i risultati per diversi Paesi principali.

Le piattaforme per agenti possono esporre più della sola capacità di calcolo

Lo studio ha rilevato 5.223 piattaforme pubblicamente raggiungibili per la creazione di agenti e la gestione dei flussi di lavoro. Tra i prodotti identificati figurano Flowise, n8n, ComfyUI, Dify, RAGFlow, Langflow e Open WebUI Pipelines.

Queste applicazioni possono avere un impatto sulla sicurezza maggiore rispetto a un server di inferenza isolato. Il loro scopo è collegare modelli a dati e azioni, spesso memorizzando o utilizzando chiavi API OpenAI, credenziali di database, token Slack, password CRM e segreti dei webhook.

Una piattaforma per flussi di lavoro può inoltre avere l’autorizzazione a interrogare database di produzione, aggiornare i record dei clienti, accedere a repository di codice sorgente, inviare messaggi o attivare altre automazioni. L’esposizione avvicina quindi a un attaccante sia i segreti sia i percorsi di esecuzione autorizzati.

Mysterium ha identificato 1.341 istanze Flowise raggiungibili. Nessuna ha restituito una richiesta di autenticazione 401 o 403, anche se questa misurazione, da sola, non dimostra l’assenza di controlli di login a livello applicativo.

Flowise presenta anche un rischio software distinto. CVE-2026-40933 è una vulnerabilità critica dell’adattatore MCP attraverso la quale un attaccante autenticato può eseguire comandi arbitrari. Ha un punteggio CVSS pari a 9,9 e il vettore CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H.

Il problema è stato risolto in Flowise 3.1.0. Gli amministratori dovrebbero eseguire l’upgrade a questa versione o a una successiva.

L’esposizione su Internet non dimostra che un sistema Flowise rilevato utilizzi una release vulnerabile, e la falla richiede comunque un accesso autenticato. Tuttavia, un’installazione pubblicamente raggiungibile offre agli aggressori più opportunità per ottenere o riutilizzare credenziali e prendere di mira il percorso di esecuzione dei comandi.

I token fuoriusciti rendono inutile sfruttare una vulnerabilità

I rischi legati a n8n mostrano perché i responsabili della difesa non possano concentrarsi esclusivamente sui difetti del software.

In un’analisi pubblicata ad agosto, i ricercatori di GitGuardian hanno esaminato token API n8n esposti in commit pubblici su GitHub. Hanno identificato 4.576 token univoci associati a 1.255 nomi host.

Di questi host, 896 erano raggiungibili durante i test. Almeno un token fuoriuscito funzionava contro 321 istanze.

In questi casi, all’attaccante non serve una vulnerabilità. Un token valido può fornire accesso diretto ai flussi di lavoro e alle relative integrazioni, a seconda dei privilegi e della configurazione dell’istanza interessata.

Questo rende le installazioni n8n e Flowise collegate ad ambienti di produzione archivi di credenziali di grande valore. Un token fuoriuscito attraverso il codice sorgente può diventare il punto di ingresso, mentre un piano di controllo pubblicamente accessibile offre all’attaccante un luogo in cui utilizzarlo.

I responsabili della difesa dovrebbero esaminare i repository e la cronologia dei commit, non soltanto la versione corrente di un progetto. Rimuovere un segreto dall’ultima revisione non invalida le copie conservate nei commit precedenti, nei fork, nei log o nelle cache. Qualsiasi credenziale che si sospetti essere stata esposta deve essere ruotata.

I vector store introducono un rischio distinto di esposizione dei dati

Mysterium ha contato 920 endpoint per vector store raggiungibili, quasi tutti con console di gestione Attu per Milvus. Questa categoria è particolarmente incompleta perché la fonte di scansione non copriva le porte native utilizzate dai database Qdrant e Milvus.

Un database vettoriale può quindi rimanere pubblicamente raggiungibile senza comparire nel totale.

Questi sistemi memorizzano embedding e contenuti associati utilizzati dalle applicazioni di IA per recuperare le informazioni pertinenti. A seconda dell’installazione, questi materiali possono includere documenti interni, ticket di assistenza, record dei clienti, istruzioni operative o voci private delle basi di conoscenza.

Una console di gestione esposta e un’interfaccia esposta del database nativo rappresentano inoltre problemi di rilevamento diversi. I team di sicurezza che eseguono scansioni solo sulle porte web convenzionali possono trovare Attu e non rilevare il database sottostante, o viceversa.

Lo studio non ha esaminato le raccolte né recuperato record, quindi non dimostra che i dati fossero accessibili da uno dei 920 endpoint. Dimostra però che le superfici di gestione erano visibili da Internet.

I responsabili della difesa dovrebbero ridurre l’esposizione prima di indagare su una compromissione

Le organizzazioni dovrebbero iniziare creando un inventario dei server per modelli, delle piattaforme per agenti, dei motori per flussi di lavoro, dei database vettoriali e delle relative console di gestione. Gli asset cloud e gli esperimenti temporanei con l’IA meritano particolare attenzione, perché dopo i test i servizi possono rimanere associati a 0.0.0.0.

Quando la connettività pubblica non è necessaria, i servizi dovrebbero essere in ascolto solo su localhost o su interfacce di rete private. I sistemi che richiedono accesso remoto hanno bisogno di autenticazione, abbinata a controlli perimetrali, segmentazione e restrizioni sulle reti sorgente autorizzate.

Le azioni prioritarie includono:

• Eseguire l’upgrade di Flowise alla versione 3.1.0 o successiva.
• Cercare nei repository di codice e nella cronologia dei commit chiavi API, token n8n, password di database, segreti dei webhook e altre credenziali.
• Ruotare i segreti che potrebbero essere transitati attraverso flussi di lavoro esposti o repository pubblici.
• Limitare l’esecuzione non necessaria di strumenti, l’esecuzione di codice, l’accesso alle API e le integrazioni esterne.
• Proteggere le console Attu ed eseguire scansioni separate per individuare le interfacce native di Milvus e Qdrant.
• Monitorare richieste di inferenza impreviste, utilizzo delle GPU, modifiche ai flussi di lavoro, uso dei token e attività nei sistemi collegati.
• Utilizzare le impronte dei prodotti nei servizi di scansione Internet per individuare gli asset dell’organizzazione visibili dall’esterno della rete.

Lo studio non ha confermato alcuna compromissione. La sua conclusione pratica è più circoscritta, ma comunque significativa: decine di migliaia di componenti di IA riconoscibili sono raggiungibili da Internet e molti non mostrano alcun meccanismo di accesso rilevabile prima dell’applicazione stessa.