Censys: infrastrutture AI esposte +63%, n8n concentra il nuovo rischio Internet

🛡️ Executive Summary

• Censys rileva una crescita del 63% delle infrastrutture AI esposte pubblicamente su Internet nell’arco di nove mesi.
• Il 76% degli host n8n con versione identificabile risulta associato a una vulnerabilità critica, ma questo non significa che sia già compromesso.
• Gateway LLM, server MCP e orchestratori concentrano token e privilegi, trasformando lo shadow AI in una nuova superficie d’attacco aziendale.

L’adozione dell’intelligenza artificiale sta aumentando rapidamente la superficie esposta su Internet. Censys rileva una crescita del 63% delle infrastrutture AI pubblicamente raggiungibili in nove mesi e individua in n8n uno dei segnali più preoccupanti: il 76% degli host per i quali è possibile determinare la versione risulta associato a una vulnerabilità critica. Il dato non significa che il 76% delle installazioni sia compromesso, ma fotografa un problema strutturale: workflow agentici, gateway LLM, server MCP e piattaforme di automazione vengono pubblicati come normali servizi web pur custodendo token, credenziali cloud e capacità di esecuzione. Lo shadow IT dell’AI sta diventando infrastruttura direttamente interrogabile da Internet.

Censys misura la crescita dell’AI esposta e il problema non è il modello

Nel 2026 State of the Internet Report di Censys, la società mette al centro l’espansione delle infrastrutture AI raggiungibili dall’esterno e quantifica in +63% la crescita osservata nell’arco di nove mesi. La superficie comprende strumenti costruiti per servire modelli, workflow, agenti e automazioni, quindi non coincide con semplici chatbot pubblici. Il rischio nasce dal fatto che questi componenti operano spesso molto più vicino alle identità aziendali rispetto al modello: possono possedere API key, chiamare database, raggiungere repository, invocare strumenti MCP o eseguire workflow con privilegi reali. È la stessa concentrazione di potere emersa quando LiteLLM è risultato esposto con configurazioni deboli, RCE e accesso alle credenziali IAM. Un gateway AI compromesso non consegna necessariamente soltanto una conversazione: può aprire l’accesso a tutti i provider e servizi che quel gateway è stato progettato per centralizzare.

Leggi anche: Veeam, Terraform MCP e n8n espongono credenziali e accessi aziendali

Il 76% degli n8n con versione nota non è “hackerato” ma resta un segnale enorme

Il secondo dato richiede una distinzione precisa. Censys afferma che il 76% degli host n8n con versione identificabile è interessato da una vulnerabilità critica; non afferma che tre installazioni su quattro siano state compromesse né che ogni host esposto sia sfruttabile nelle stesse condizioni. La percentuale misura l’esposizione potenziale e soprattutto il ritardo tra disclosure e aggiornamento. n8n è particolarmente sensibile perché un workflow può concentrare credenziali SaaS, token API, database, email, strumenti interni e automazioni con capacità operative. Le falle RCE già emerse sui server n8n self-hosted avevano mostrato che una vulnerabilità nella piattaforma non resta confinata all’applicazione: il vero impatto dipende da quali segreti e sistemi il workflow può raggiungere. Censys trasforma quel rischio puntuale in un dato Internet-wide e mostra quanto lentamente parte dell’ecosistema stia riducendo l’esposizione.

Langflow e LiteLLM mostrano perché i tool AI stanno diventando target ad alto rendimento

Il rischio cresce perché molti strumenti AI sono progettati precisamente per collegare risorse differenti. Langflow costruisce catene e agenti, LiteLLM centralizza l’accesso ai provider, n8n orchestra workflow e MCP collega i modelli a strumenti eseguibili. Il risultato è una concentrazione di privilegi che rende ogni istanza esposta più appetibile di una normale applicazione web. Gli attacchi reali contro Langflow hanno già puntato a variabili d’ambiente, chiavi cloud, credenziali OpenAI e accessi SSH, mentre le campagne su LiteLLM hanno dimostrato che un gateway vulnerabile può ampliare l’impatto fino a provider multipli e ruoli cloud. L’asimmetria è evidente: l’organizzazione installa un singolo componente per semplificare l’AI enterprise, l’attaccante vede nello stesso componente un punto unico dal quale tentare di ereditare tutte le relazioni di fiducia costruite intorno al modello.

MCP trasforma l’esposizione di rete in una questione di autorizzazioni

La diffusione dei server MCP aggiunge un ulteriore livello perché sposta la superficie d’attacco dal semplice accesso al modello verso gli strumenti che il modello può invocare. Un endpoint MCP può rappresentare un database, un repository, un file system, una piattaforma SaaS o una funzione amministrativa. Esporlo senza autenticazione robusta, con trust boundary deboli o attraverso un gateway vulnerabile significa offrire a un attaccante qualcosa di più utile di una risposta LLM: una funzione autorizzata. Le vulnerabilità MCP che hanno portato a RCE in framework e strumenti AI avevano già mostrato che la sicurezza agentica dipende dall’infrastruttura che circonda il modello almeno quanto dai guardrail del modello stesso. La fotografia Censys rende questa distinzione operativa: più agenti e automazioni diventano pubblicamente raggiungibili, più inventario, autenticazione, segmentazione e controllo degli strumenti diventano prerequisiti della sicurezza AI.

Per le imprese il problema è scoprire l’AI prima degli attaccanti

La risposta non consiste semplicemente nel chiudere ogni servizio AI verso Internet. Alcuni deployment devono restare raggiungibili e servire applicazioni esterne. Il punto è sapere esattamente quali componenti siano pubblici, quale versione eseguano, chi li gestisca e quali credenziali possano utilizzare. Serve quindi una gestione della superficie d’attacco che includa gateway LLM, server MCP, orchestratori e tool self-hosted. Anche la remediation deve cambiare: dopo una RCE o un authentication bypass non basta aggiornare il pacchetto, ma occorre verificare workflow, token, sessioni e segreti downstream. Le campagne già entrate nel catalogo KEV contro LiteLLM e altri componenti AI mostrano che l’esposizione non è più teorica.

Continua con:

CISA impone patch urgenti mentre LiteLLM e Veeam espongono infrastrutture critiche

L’AI enterprise sta creando il proprio shadow infrastructure

Il dato Censys sintetizza un passaggio che il mercato tende ancora a leggere come semplice accelerazione dell’adozione: ogni nuovo agente porta con sé infrastruttura, identità e connettività. Quando questi livelli vengono distribuiti rapidamente da team differenti, spesso attraverso progetti self-hosted e container pronti all’uso, nasce una nuova forma di shadow infrastructure che può sfuggire ai processi tradizionali di asset management. Non è necessario che il modello sia vulnerabile perché l’intero sistema AI diventi un punto di ingresso; basta un orchestratore non aggiornato, un gateway pubblicato con autenticazione debole o un server MCP che esponga strumenti troppo potenti. Il +63% osservato da Censys deve quindi essere letto meno come misura del successo commerciale dell’AI e più come indicatore della velocità con cui una nuova superficie si sta materializzando su Internet. Gli attaccanti non devono inventarla: possono già scandirla, classificarla e aspettare che una vulnerabilità trasformi l’esposizione in accesso.