Attori malevoli colpiscono attivamente i modelli linguistici di grande scala (LLM) attraverso campagne coordinate che combinano ricognizione sistematica, sfruttamento di debolezze applicative e fingerprinting silenzioso. Le osservazioni raccolte tra ottobre 2025 e gennaio 2026 delineano un cambio di passo: l’attenzione non è più solo sull’abuso dei prompt, ma sull’infrastruttura che ospita i modelli, sulle integrazioni di contorno e sui servizi di automazione che li collegano ai processi aziendali.
Due filoni operativi emergono con chiarezza. Il primo sfrutta Server-Side Request Forgery (SSRF) per forzare i server AI a connettersi verso infrastrutture controllate dagli attaccanti, validando superfici d’attacco e preparando exploit successivi. Il secondo conduce un’enumerazione metodica degli endpoint LLM, usando query apparentemente innocue per mappare modelli, versioni e compatibilità senza attivare allarmi. In parallelo, una vulnerabilità critica sull’automazione open source n8n — denominata Ni8mare — espone decine di migliaia di istanze a RCE senza autenticazione, amplificando l’impatto su ambienti che integrano AI, dati e credenziali.
Cosa leggere
Campagne SSRF contro implementazioni AI: validare oggi, sfruttare domani
La campagna SSRF osservata sfrutta funzionalità operative legittime per indurre richieste in uscita verso domini controllati dagli attaccanti. Un caso emblematico riguarda il pull dei modelli in Ollama: l’iniezione di URL di registry malevoli consente di attivare callback HTTP verso infrastrutture avversarie, confermando l’esistenza di egress aperti e l’assenza di controlli restrittivi. Tra ottobre 2025 e gennaio 2026 sono state osservate 91.403 sessioni su honeypot dedicati, con un picco di 1.688 sessioni in 48 ore durante il periodo natalizio.

La stessa logica SSRF colpisce integrazioni webhook, come quelle SMS di Twilio, manipolando parametri come MediaUrl per forzare connessioni verso server esterni. L’obiettivo non è l’esfiltrazione immediata, ma la convalida della superficie: verificare quali implementazioni AI consentono chiamate in uscita, con quali header, verso quali TLD.
Un indicatore tecnico ricorrente rafforza l’ipotesi di tooling condiviso. Una firma JA4H compare nel 99% delle sessioni, suggerendo l’uso di strumenti standardizzati di ricognizione come Nuclei e componenti OAST di ProjectDiscovery. Le infrastrutture coinvolgono 62 IP in 27 Paesi, prevalentemente su VPS, con callback verso domini OAST noti. La campagna dimostra maturità operativa: jitter temporale, retry controllati e rate di richiesta calibrati per evitare soglie di alert.
Enumerazione silenziosa degli endpoint LLM: mappare senza farsi vedere
In parallelo, dal 28 dicembre 2025 prende forma una campagna distinta di enumerazione endpoint, che in undici giorni totalizza 80.469 sessioni e testa oltre 73 endpoint LLM. La tattica è raffinata: richieste compatibili con le API di OpenAI e Google Gemini, ma formulate come domande banali — quante sono le capitali, quante “r” in “strawberry” — per fingerprintare il modello rispondente senza generare rumore.
Il perimetro sondato include modelli diffusi e alternativi, da GPT-4o a Claude Sonnet, Llama 3.x, DeepSeek-R1, Mistral, Qwen e Grok. I pattern mostrano una progressione ordinata: endpoint base, varianti, parametri, timeout. Due IP principali guidano l’attività, con origini in USA e Paesi Bassi. Anche qui, l’obiettivo non è l’abuso immediato, ma la cartografia dell’esposizione: sapere chi risponde, come, con quale compatibilità, per predisporre attacchi mirati futuri.
Ni8mare: RCE critica su n8n che amplifica l’impatto sulle catene AI
Il terzo elemento cambia la scala del rischio. Ni8mare è una vulnerabilità con CVSS 10.0 che consente esecuzione remota di codice senza autenticazione su n8n, piattaforma largamente usata per orchestrare workflow, integrazioni e automazioni — spesso proprio attorno a LLM e servizi AI.
La falla risiede in una gestione errata dell’intestazione Content-Type nelle richieste verso webhook e nodi Form. Se il Content-Type non corrisponde a quanto atteso, il parser popola req.body.files con dati controllati dall’attaccante, consentendo di iniettare percorsi di file locali mascherati da upload legittimi. Da qui, l’accesso a file sensibili è diretto: configurazioni, segreti e — soprattutto — il database SQLite.
Con le chiavi di cifratura estratte dal file di configurazione, l’attaccante può generare token amministrativi, creare workflow e usare nodi come Execute Command per lanciare comandi arbitrari. In ambienti self-hosted con permessi elevati, l’impatto è devastante. Le stime indicano oltre 26.000 istanze esposte su internet, centinaia in Italia. Le versioni precedenti alla 1.121.0 sono vulnerabili; l’aggiornamento è l’unica mitigazione risolutiva.
Perché queste campagne sono collegate
SSRF, enumerazione LLM e Ni8mare non sono eventi isolati. Insieme descrivono una catena d’attacco plausibile: mappare i modelli e gli endpoint, verificare l’egress e le integrazioni, poi colpire i collanti dell’ecosistema — le automazioni — per ottenere RCE e controllo persistente. In organizzazioni dove n8n collega LLM, database, CRM e servizi di pagamento, la compromissione diventa trasversale: password, chiavi API, dati e processi.
Difesa: cosa cambia davvero per le implementazioni AI
Le misure efficaci non sono cosmetiche. Per le piattaforme LLM è essenziale limitare i registry consentiti, chiudere l’egress con allowlist, bloccare domini OAST noti e monitorare firme JA4 e pattern di retry/jitter. L’enumerazione va intercettata con rate-limit intelligenti, alert su rapid-fire multi-endpoint e analisi di query di fingerprinting apparentemente innocue.
Per n8n, la priorità è aggiornare alla 1.121.0 o successive, ridurre l’esposizione diretta a internet, adottare segmentazione di rete, VPN, e verificare segni di compromissione: workflow non autorizzati, nuovi utenti, escalation improvvise, accessi ai path standard del database. In generale, serve un cambio di mentalità: dalla difesa statica alla behavioral detection, dalla fiducia implicita alle policy di minimo privilegio.
L’AI è un bersaglio infrastrutturale
Queste campagne mostrano che gli attori malevoli trattano l’AI come infrastruttura critica, non come semplice applicazione. Colpire i LLM significa colpire pipeline, integrazioni e automazioni. La risposta richiede vigilanza continua, aggiornamenti rapidi e una lettura sistemica del rischio. Chi protegge solo il modello e ignora ciò che gli sta attorno resta esposto.
Domande frequenti sugli attacchi ai modelli LLM
Perché gli attacchi SSRF sono pericolosi per le implementazioni AI?
Perché consentono di forzare connessioni in uscita dai server AI, validando l’egress e aprendo la strada a exploit successivi senza toccare direttamente il modello.
Cos’è l’enumerazione degli endpoint LLM?
È una ricognizione silenziosa che usa query banali per identificare modelli, versioni e compatibilità API, evitando allarmi e preparando attacchi mirati.
Perché Ni8mare è così critica per chi usa AI?
Perché n8n spesso orchestra workflow AI. Una RCE senza autenticazione consente di prendere il controllo delle catene che collegano LLM, dati e credenziali.
Qual è la mitigazione più efficace contro Ni8mare?
Aggiornare a n8n 1.121.0 o successive e ridurre l’esposizione diretta a internet; non esistono workaround equivalenti.