Honeypot AI: attacchi reali a LiteLLM e MCP server, tre pattern scoperti

Wiz Threat Research ha messo in campo honeypot su servizi AI/ML per 90 giorni e documentato attacchi sostenuti con tooling specificamente adattato agli interni di ciascun servizio. Il 27 agosto 2026 il team ha pubblicato i risultati: non si tratta di probing generico, ma di exploit mirati contro orchestratori come LiteLLM, LangChain, Flowise e Ollama, con tecniche di post-exploitation che sfruttano la struttura stessa dei framework Python. La posta in gioco è un'infrastruttura AI ormai mainstream: secondo la fonte, il 90% degli ambienti cloud esegue software AI self-hosted, l'81% gestisce servizi AI e il 63% ospita modelli self-hosted.

Pattern uno: RCE via MCP server e la catena di bypass

Il primo pattern documentato sfrutta CVE-2026-42271, command injection negli endpoint POST /mcp-rest/test/connection e POST /mcp-rest/test/tools/list di LiteLLM. Il vettore passa attraverso subprocess senza validazione: un payload Python scarica ed esegue il miner 'gmon' con start_new_session=True, rimuove la directory staging con rmtree e mantiene persistenza tramite inode aperto in memoria. L'output del comando viene restituito via campo description nella risposta tools/list.

La catena diventa critica con CVE-2026-59822, authentication bypass nel LiteLLM MCP Gateway: qualsiasi Bearer token, incluso un singolo carattere 'x', restituisce un oggetto UserAPIKeyAuth() vuoto con accesso MCP completo. Wiz ha osservato questo comportamento in honeypot con probe di model enumeration. Concatenando CVE-2026-42271 con CVE-2026-48710 (Starlette host header bypass), il report documenta RCE completamente non autenticato.

"Over 90 days of telemetry, we observed sustained attack activity against AI infrastructure, with tooling adapted to the specific internals of each service" — Wiz Threat Research

Pattern due: blind prompt injection e exfiltrazione OAST

Il secondo pattern colpisce LangChain, Flowise, OpenWebUI e Node-RED. Si tratta di prompt progettati per eseguire comandi OS con callback DNS a dominio controllato dal threat actor (OAST), con indirizzo IP codificato in subdomain e stringa random per tracciamento di sessione. I payload successivi arrivano da Pastebin, base64-encoded per bypassare filtri. Questo vettore rappresenta un'evoluzione della superficie di attacco: non più injection nel modello in sé, ma contro il framework agenti che lo avvolge.

Wiz sottolinea che la blind prompt injection è ricostruita sulla base di process tree e callback DNS, non catturata in flagrante con payload intercettato. Il percorso di deployment di XMRig in /usr/src/node-red/xmrig mostra tecnica di mimetizzazione con il process tree Node.js: il miner si presenta come componente legittima dell'infrastruttura.

Pattern tre: post-exploitation che parla Python

Il terzo pattern è la post-exploitation specializzata per ambienti AI. Invece di cercare file di credenziali su disco, gli attacker interrogano direttamente lo stato del modulo Python in esecuzione per estrarre la master key dalla memoria. La tecnica è efficace perché la chiave non risiede in un file ma nel modulo caricato. Da lì l'attaccante enumera i backend model per LLMjacking.

I percorsi di configurazione specifici osservati sono /app/litellm_config.yaml, /etc/litellm/.env e ~/.litellm/config.yaml. Il camuffamento raggiunge livello raffinato: su honeypot Langflow, un miner è stato piazzato in /app/data/.claude/ e rinominato 'unicorn'. La directory .claude/ è config legittima di Claude Code, quindi non desta sospetti in un server AI.

"Rather than searching for credential files on disk, attackers queried the running process's Python module state directly to extract the master key from memory, since it doesn't exist in a file on the disk" — Wiz Threat Research

La geografia del rischio: quando l'AI tooling diventa superficie

I numeri di esposizione sono parte integrante del problema. Secondo il report Wiz, il 57% delle organizzazioni deploya agenti AI self-hosted, l'80% adotta server MCP, e 1/6 ambienti espone almeno un MCP server pubblicamente. Di questi, circa il 70% restituisce catalogo tool anonimamente e circa il 42% dati reali. La combinazione di credential concentration nei gateway AI e agent reachability nei framework agenti amplifica l'impatto di ogni singola compromissione.

Il report collega il gruppo Qilin ransomware a exploit attivo della catena CVE-2026-42271/CVE-2026-48710. L'estensione effettiva della compromissione da parte di Qilin al di fuori degli honeypot non è quantificata nel dossier.

Perché è importante

Il dossier non specifica misure correttive generali o framework di mitigazione oltre alla patch 1.83.7 per CVE-2026-42271. Non documenta raccomandazioni specifiche per la blind prompt injection o per la post-exploitation da stato Python. Il brief non elenca secrets, SSH keys, source code, host filesystem o credenziali come categorie di dato esposto: la fonte si limita a documentare le tecniche di estrazione e i percorsi osservati.

Sulla cronologia, il periodo di 90 giorni non ha date di inizio e fine assolute nel report; la conclusione è presumibilmente prossima al 27 agosto 2026. La data di inserimento in CISA KEV del 8 giugno 2026 per CVE-2026-42271 si basa sulla sola fonte Wiz. Per CVE-2026-48710 e CVE-2026-59822 il report è al momento l'unica fonte disponibile: non risultano record NVD verificati indipendentemente. Il volume quantitativo esatto di attacchi e la geolocalizzazione degli IP attacker non sono specificati.

Il report Wiz non copre supply chain npm (keyv/cacheable), che è ricerca separata. Non tutti i MCP server sono configurati per esposizione anonima: il rischio dipende da backend e autenticazione attiva.

FAQ

Cos'è la post-exploitation "nativa-AI" documentata da Wiz?

È l'uso di tecniche specifiche per l'ecosistema AI: estrazione di chiavi da stato modulo Python in memoria, enumerazione backend LLM per LLMjacking, piazzamento di malware in directory legittime dell'AI tooling (.claude/) per mimetizzazione. Non è generica post-exploitation Linux: è calibrata sugli artefatti e i processi dei framework AI.

Perché il mining è rilevante in un report su infrastruttura AI?

Il mining (gmon, XMRig) è il payload osservato, ma il vettore è il punto: RCE su orchestratori AI e prompt injection su framework agenti. La scelta del payload mostra che gli attacker considerano questa infrastruttura come qualsiasi altra superficie computazionale, con il vantaggio aggiunto di credential concentration e accesso ai modelli.

Cosa distingue la blind prompt injection di questo report da attacchi noti a LLM?

Non colpisce il modello in conversazione ma il framework agenti che lo orchestra (LangChain, Flowise, Node-RED). Il payload non è visibile all'utente finale ma eseguito nel contesto del processo agente, con exfiltrazione via callback DNS OAST. La fonte la ricostruisce da process tree e DNS log, non da payload intercettato in diretta.

Fonti

• https://www.wiz.io/blog/ai-infrastructure-honeypot
• https://nvd.nist.gov/vuln/detail/CVE-2026-42271
• https://www.wiz.io/reports/state-of-ai-in-the-cloud-2026
• https://www.wiz.io/blog/the-risk-hiding-behind-exposed-mcp-servers
• https://www.wiz.io/blog/keyv-and-cacheable-npm-supply-chain-attack

Le informazioni sono basate sulla fonte citata e aggiornate al momento della pubblicazione.

Fonti