Langflow CVE-2026-9198: RCE non autenticata nel control plane dei tuoi agenti AI

La macchina che orchestra i tuoi agenti AI è diventata una shell pre-autenticazione per chiunque riesca a raggiungerla sulla rete. Il 4 agosto 2026 CISA ha inserito CVE-2026-9198 — una falla di remote code execution non autenticata in Langflow di IBM — nel suo catalogo Known Exploited Vulnerabilities. Due dettagli meritano una sosta. Primo: è una RCE completa su un deployment di default, senza credenziali, CVSS 9.8. Secondo: la telemetria di sfruttamento mostra attacchi a partire dal 6 luglio 2026 — undici giorni prima che il vendor pubblicasse l'advisory. Questo bug è stato colpito come uno zero-day prima ancora che esistesse qualcosa da patchare, e i sensori di KEVIntel hanno registrato un tentativo di sfruttamento ancora oggi.

Langflow è un costruttore visuale di pipeline per LLM e agenti. È esattamente per questo che una RCE non autenticata qui non è l'ennesima applicazione web che cade: è il control plane dell'intera flotta di agenti di un'organizzazione consegnato a uno sconosciuto.

La catena di due richieste che trasforma Langflow in una shell

La vulnerabilità, classificata come CWE-94 (code injection), non è un sottile gadget di corruzione della memoria. È una catena logica di due chiamate REST che non erano mai state pensate per essere raggiungibili insieme da un chiamante anonimo:

1. POST /api/v1/auto_login — endpoint pensato come comodità per lo sviluppo locale, che emette una sessione SUPERUSER. Non è vincolato al loopback e non impone autenticazione, quindi consegna un token SUPERUSER a qualunque chiamante di rete.
2. POST /api/v1/validate/code — con quel token in mano, questo endpoint esegue codice Python fornito dall'attaccante tramite exec() sull'host sottostante.

L'exploit è tutto qui. Niente heap grooming, niente catena ROP, nessun leak di memoria per sconfiggere l'ASLR. Un attaccante che riesca ad aprire un socket TCP verso la porta di Langflow ottiene un token SUPERUSER dalla prima richiesta e l'esecuzione di codice arbitrario dalla seconda. Il vettore CVSS — AV:N/AC:L/PR:N/UI:N/C:H/I:H/A:H — si legge così perché ogni dimensione è nel peggior caso possibile: raggiungibile in rete, bassa complessità, nessun privilegio, nessuna interazione utente.

"La macchina è esposta su internet?" è la prima domanda sbagliata. Quella giusta è: "Qualcosa che l'attaccante già controlla — una workstation compromessa, un container ostile, un host su cui ha fatto pivoting — può raggiungere la porta TCP del servizio Langflow?" Per un'installazione di default la risposta è quasi sempre sì, ed è tutto ciò che serve all'exploit.

Il codice proof-of-concept è pubblico dal 21 luglio 2026 e un template di rilevamento Nuclei è arrivato il 29 luglio. Quando CISA l'ha inserita in KEV, era ormai un attacco punta-e-clicca.

Perché una RCE non autenticata in Langflow è peggio di una RCE web qualsiasi

Una RCE generica dà all'attaccante un server applicativo. Una RCE in Langflow gli dà la cassaforte delle credenziali di tutto ciò che sta a valle. Consideriamo cosa contiene davvero un'istanza Langflow, in memoria e su disco:

• Chiavi API dei provider di modelli — OpenAI, Anthropic, Azure, endpoint di inferenza self-hosted. Memorizzate perché i flow possano chiamarli.
• Credenziali degli strumenti — i token che ogni agente usa per raggiungere Slack, GitHub, API interne, sistemi di ticketing.
• Stringhe di connessione ai database — i flow di retrieval hanno bisogno di accesso in lettura (e spesso in scrittura) ai data store di produzione.
• Egress ampio — un orchestratore di agenti è progettato per fare chiamate in uscita verso servizi arbitrari, quindi la policy di rete attorno a esso è di solito permissiva.

Un attaccante con exec() su questo host non deve scalare da nessuna parte. Legge le configurazioni dei flow, raccoglie ogni segreto ed eredita la posizione di rete di un servizio costruito per parlare con tutto. Questo è il vettore d'ingresso che le famiglie di ransomware agentico sfruttano una volta all'interno — la stessa classe di piattaforma di cui abbiamo scritto nell'analisi di JADEPUFFER. CVE-2026-9198 è il modo in cui ottengono il primo appoggio.

La cronologia dello sfruttamento: colpita come zero-day, patchata per seconda

Qui le date contano più del solito, perché mostrano un modello difensivo che fallisce in un modo preciso. Secondo KEVIntel e The Hacker News:

Data	Evento
2026-05-21	CVE-2026-9198 riservata
2026-07-06	Primo sfruttamento osservato in-the-wild
2026-07-17	IBM pubblica l'advisory e rilascia la fix
2026-07-21	Rilascio del proof-of-concept pubblico
2026-07-29	Rilascio del template scanner Nuclei
2026-08-04	Inserimento nel catalogo CISA KEV
2026-08-13	Tentativi di sfruttamento ancora osservati

Vanno lette insieme le prime due righe. Gli attacchi sono iniziati undici giorni prima che l'advisory del vendor esistesse. Per quegli undici giorni non c'era un CVE da confrontare, né una patch da applicare, né una firma da caricare — eppure il traffico era già lì: 650 tentativi di sfruttamento da 244 indirizzi IP unici in 41 paesi quando The Hacker News ha riportato l'inserimento in KEV, e la telemetria di KEVIntel è da allora salita a 762 tentativi da 298 IP in 42 paesi con 159 user-agent distinti al 13 agosto. Non è stata un'operazione mirata contro una singola vittima; è stato scanning opportunistico su scala internet che ha individuato una classe di bersaglio — i costruttori di agenti esposti — e l'ha innaffiata.

Qualunque difesa che aspetti un numero CVE, una patch del vendor o un feed di IOC è stata strutturalmente cieca per quella finestra. Le richieste stesse erano l'unica evidenza, ed erano sul filo per tutto il tempo.

Remediation

Considera compromessa qualunque istanza Langflow raggiungibile da internet e più vecchia della 1.10.1, fino a prova contraria. Lo sfruttamento precede la patch, quindi "abbiamo aggiornato in fretta" non equivale a "non siamo mai stati colpiti".

1. Sono interessato?

Le versioni dalla 1.0.0 alla 1.10.0 sono vulnerabili. Verifica la versione installata e se gli endpoint vulnerabili rispondono:

# Versione installata
pip show langflow | grep -i version
# oppure, per un'immagine container
docker inspect <image> --format '{{index .Config.Labels "org.opencontainers.image.version"}}'

# auto_login consegna un token a un chiamante anonimo? (eseguire da un host non-loopback)
curl -s -X POST http://<host>:7860/api/v1/auto_login | grep -o 'access_token'

Se auto_login restituisce un access_token a una richiesta remota e non autenticata, l'istanza è sfruttabile adesso. Dai priorità a tutto ciò che è esposto su internet, poi a tutto ciò che è raggiungibile dalle subnet utente o dalle reti CI/CD.

2. Patch — versione corretta esatta

Aggiorna a Langflow 1.10.1 o successiva, la prima release che corregge CVE-2026-9198. Le versioni dalla 1.0.0 alla 1.10.0 sono interessate; la 1.10.1 è la baseline corretta, confermata sia dal record NVD sia dall'advisory IBM di luglio.

pip install --upgrade "langflow>=1.10.1"
# containerizzato
docker pull langflowai/langflow:1.10.1

3. Non puoi patchare subito? Controlli compensativi

• Mettila dietro autenticazione. Poni davanti all'istanza un reverse proxy autenticante o una VPN, così /api/v1/auto_login non è mai raggiungibile da un chiamante non autenticato.
• Blocca i due endpoint sul proxy. Se non puoi aggiornare subito, nega POST /api/v1/auto_login e POST /api/v1/validate/code a livello di WAF/proxy per ogni sorgente esterna.
• Rimuovi l'esposizione su internet. Una UI di agent-builder non ha motivo di essere elencata pubblicamente. Vincolala a un'interfaccia interna.
• Segmenta l'egress. Limita il traffico in uscita dall'host Langflow perché un'istanza compromessa non possa raggiungere gli endpoint di metadata cloud (169.254.169.254), i database interni o i bersagli laterali. Questo contiene il raggio d'azione anche dopo l'exec().

4. Caccia alla compromissione

Poiché lo sfruttamento è avvenuto prima di ogni advisory, il rilevatore affidabile è l'analisi dei log, non il pattern matching su firme. Mappa l'attività su MITRE ATT&CK:

• T1190 — Exploit Public-Facing Application. Cerca negli access log POST /api/v1/auto_login e POST /api/v1/validate/code, in particolare da IP sorgente esterni o inattesi. Risposte 2xx a auto_login da chiamanti non-loopback sono il segnale singolo più forte. Il template Nuclei pubblicato il 29 luglio codifica la forma della richiesta.
• T1059.006 — Command and Scripting Interpreter: Python. Cerca processi figli anomali generati dal worker di Langflow: shell (/bin/sh, bash), curl/wget, gestori di pacchetti o interpreti che un flow normale non lancia mai.
• T1552 / T1528 — Unsecured Credentials / Steal Application Access Token. Qualunque lettura dei file di configurazione dei flow o del secrets store subito dopo una chiamata validate/code è furto di credenziali in corso.
• T1071 / T1496 — C2 a livello applicativo / Resource Hijacking. Connessioni in uscita verso ASN mai visti prima, o un nuovo carico CPU sostenuto compatibile con cryptomining, dopo un exec sull'host.

L'insieme di 298 IP è opportunistico e ruota, quindi non costruire il rilevamento solo su una blocklist statica di IP — dai priorità al comportamento (emissione anonima di token SUPERUSER → esecuzione di codice → traffico in uscita) rispetto a qualunque singolo indicatore.

5. Eradica e verifica

La patch chiude la porta; non annulla ciò che è già uscito. Se trovi uno sfruttamento riuscito — o non puoi provare di non essere stato colpito durante la finestra pre-patch — allora:

• Ruota ogni segreto raggiungibile dall'istanza. Ogni chiave API dei provider di modelli, ogni token degli strumenti, ogni credenziale di database referenziata da qualunque flow memorizzato. La RCE ha dato all'attaccante accesso in lettura a tutti; la patch non li ruota al posto tuo.
• Ricostruisci, non ripulire. Ridistribuisci l'host o il container da un'immagine nota-buona invece di tentare di rimuovere un impianto sul posto.
• Conferma la bonifica dopo la patch. Riesegui il probe di auto_login da un host remoto e verifica che ora rifiuti il chiamante anonimo, poi ricontrolla le baseline di processi ed egress per 72 ore.

Catturare l'onda, non l'articolo

La lezione scomoda di questo CVE è la finestra di undici giorni tra il primo sfruttamento e il primo advisory. In quella finestra l'unico artefatto esistente era il traffico stesso — la chiamata anonima ad auto_login, il payload di validate/code, il beacon in uscita che seguiva. È esattamente il punto cieco che l'AI Traffic Analysis di Zero Hunt è stata costruita per chiudere: un modello di deep learning proprietario con quattro teste di inferenza parallele (traffico sospetto, classificazione malware, identificazione del tipo di attacco, fingerprinting applicativo), addestrato su miliardi di sequenze PCAP, in esecuzione localmente sulla GPU dell'appliance a 2.7+ Gbit/s. Segnala la sessione anomala — una sorgente mai vista che emette un token privilegiato, poi un host che storicamente solo riceve dati che improvvisamente fa beaconing verso un ASN sconosciuto — mentre sta accadendo, non nel digest del SIEM del mattino dopo e non subordinato all'esistenza di un numero CVE.

L'altra metà è non aspettare che qualcuno ti dica che un bug esiste. Il motore generativo a 10 agenti di Zero Hunt scrive una catena di exploit fresca per ogni bersaglio — la sua stessa prova auto_login-verso-validate/code contro la tua istanza reale — validata nell'AI Gym contro un corpus di oltre 142 skill auto-evolutive prima di girare in produzione, con ogni finding firmato in ECDSA per la catena di custodia. Le campagne continue e attivate dai cambiamenti fanno sì che una nuova istanza Langflow esposta sul tuo perimetro venga testata entro l'ora in cui appare, non al prossimo pentest annuale. La scelta che questo CVE impone è tra trovare la tua RCE non autenticata prima di 298 sconosciuti, e leggerla in una voce di KEV con undici giorni di ritardo. Parliamone: decidi tu su quale lato di quegli undici giorni vuoi stare.