Langflow sotto attacco attivo: cosa sta succedendo

Il 4 agosto 2026 la CISA (Cybersecurity and Infrastructure Security Agency statunitense) ha aggiunto CVE-2026-9198 al proprio Known Exploited Vulnerabilities Catalog, la lista delle vulnerabilità sfruttate attivamente in the wild. Il bersaglio è Langflow, il framework open source low-code per costruire applicazioni AI, agenti e pipeline RAG (Retrieval-Augmented Generation), oggi sviluppato e supportato da IBM dopo l’acquisizione di DataStax nel 2025.

Per chi gestisce infrastrutture IT, anche solo per supportare i team che sperimentano con l’AI generativa, questa non è una notizia da ignorare: si tratta di una remote code execution non autenticata, con CVSS 9.8, su un prodotto che viene spesso esposto in rete per comodità di accesso ai team di sviluppo.

Il dettaglio tecnico della vulnerabilità

CVE-2026-9198 nasce dalla combinazione di due endpoint API di Langflow che, singolarmente, sarebbero problemi di severità minore ma che, incatenati, diventano un disastro:

• /api/v1/auto_login — su un’installazione con la configurazione di default, questo endpoint rilascia un bearer token con privilegi SUPERUSER a qualsiasi chiamante di rete, senza richiedere credenziali.
• /api/v1/validate/code — accetta codice Python fornito dal chiamante e lo esegue tramite la funzione exec(), pensata per validare gli snippet usati nei flow visuali.

Un attaccante non autenticato può quindi ottenere il token dal primo endpoint e usarlo immediatamente per eseguire codice Python arbitrario sul secondo, ottenendo di fatto l’esecuzione di comandi con i privilegi del processo Langflow. Non serve alcuna interazione dell’utente, alcun account preesistente, né credenziali valide: è sufficiente che l’istanza sia raggiungibile in rete.

Perché la finestra di rischio è così stretta

A fine luglio 2026 sono comparsi online exploit proof-of-concept pienamente funzionanti, con istruzioni dettagliate per la weaponizzazione. Non è la prima volta che Langflow finisce sotto i riflettori: nei mesi precedenti altre vulnerabilità della piattaforma sono state sfruttate per distribuire miner di Monero e, più recentemente, in campagne di post-exploitation orchestrate da agenti AI autonomi. Uno di questi casi, documentato da Palo Alto Networks Unit 42, descrive un attore cinese che ha usato un agente basato su DeepSeek (framework Hermes) per condurre ricognizione e sfruttamento automatizzato contro oltre 460 target esposti su Internet, includendo proprio falle Langflow tra i vettori iniziali.

Le agenzie federali civili USA (FCEB) hanno una scadenza fissata al 7 agosto 2026 per applicare la correzione: un termine estremamente ravvicinato che segnala quanto la CISA consideri urgente questo caso.

Sei esposto? Come verificarlo

Se gestisci o hai installato Langflow, anche solo per test interni, verifica prima di tutto la versione in uso:

pip show langflow | grep Version
# oppure, se installato via Docker
docker exec <container> python -c "import langflow; print(langflow.__version__)"

Le versioni vulnerabili vanno dalla 1.0.0 alla 1.10.0. Se la tua istanza è raggiungibile da reti non fidate (Internet pubblico, VLAN non segmentate, VPN aziendale ad ampio accesso), il rischio è massimo. Puoi anche verificare rapidamente se l’endpoint di auto-login risponde senza autenticazione:

curl -i https://tuo-host-langflow/api/v1/auto_login

Una risposta 200 con un token JWT nel body, su un’istanza che non dovrebbe permetterlo, è un segnale da prendere sul serio.

Come mitigare e correggere

La correzione ufficiale è disponibile dal luglio 2026:

• Aggiorna a Langflow OSS 1.10.1 o superiore (al momento la release più recente è la 1.11.2). Con pip: pip install --upgrade langflow; con Docker, aggiorna il tag dell’immagine e ricrea il container.
• Non esporre Langflow direttamente su Internet. Se serve accesso remoto, mettilo dietro una VPN o un reverse proxy con autenticazione a livello di rete (es. Basic Auth via Nginx, oppure un identity-aware proxy come Cloudflare Access o OAuth2 Proxy).
• Segmenta la rete: le istanze usate per sviluppo/test AI dovrebbero stare in una VLAN dedicata, non nella stessa rete di produzione critica.
• Monitora i log applicativi per chiamate anomale a /api/v1/auto_login seguite da richieste a /api/v1/validate/code, che rappresentano l’impronta tipica di questo exploit chain.
• Se non puoi aggiornare subito, valuta di disabilitare temporaneamente l’endpoint di validazione codice a livello di reverse proxy, bloccando le richieste verso /api/v1/validate/code dall’esterno.

Il quadro più ampio: sicurezza delle piattaforme AI low-code

Questo episodio è un promemoria utile per chi valuta l’adozione di strumenti come Langflow, n8n, Flowise o piattaforme simili in ambito enterprise: sono prodotti giovani, in rapida evoluzione, spesso pensati per la produttività degli sviluppatori più che per un modello di sicurezza hardened by default. La combinazione di autenticazione permissiva e capacità di esecuzione codice arbitrario è un pattern che si ripete in questa categoria di software, ed è probabile che vedremo altre vulnerabilità simili nei prossimi mesi.

Per i sistemisti, la lezione operativa è duplice: trattare ogni piattaforma di orchestrazione AI come una superficie di attacco a tutti gli effetti (patch management, segmentazione, monitoring) e mantenere un inventario aggiornato di dove questi strumenti sono stati distribuiti, spesso al di fuori dei processi IT ufficiali grazie a shadow IT dei team di data science.

Conclusione

CVE-2026-9198 è un caso da manuale: due endpoint singolarmente poco pericolosi che, incatenati, portano a remote code execution non autenticata su un prodotto sempre più diffuso nei reparti che sperimentano con l’AI. Se hai Langflow in produzione o anche solo in un ambiente di test raggiungibile dalla rete aziendale, l’aggiornamento a 1.10.1+ va considerato prioritario, non rimandabile alla prossima finestra di manutenzione.

Fonte: The Hacker News e 4sysops.