Langflow, falla sfruttata: serve la versione 1.10.1

Una vulnerabilità di Langflow non è più soltanto una possibilità da mettere in coda. Il 4 agosto la Cybersecurity and Infrastructure Security Agency statunitense ha inserito CVE-2026-9198 nel catalogo delle vulnerabilità sfruttate attivamente. Il difetto riguarda Langflow OSS dalla versione 1.0.0 alla 1.10.0 e, nelle installazioni predefinite interessate, può consentire a un attaccante remoto senza credenziali di arrivare all’esecuzione di codice sul server. IBM indica una correzione netta: passare alla 1.10.1.

La notizia non riguarda ogni persona che usa un chatbot o un servizio di intelligenza artificiale. Il primo controllo spetta a chi ha installato e gestisce Langflow OSS su un proprio server, in un container, in una macchina virtuale o in un ambiente cloud. Chi acquista un servizio gestito deve invece chiedere al fornitore quale versione sia effettivamente in esecuzione e quando sia stata aggiornata. Confondere utenti e operatori produce allarme dove non serve e ritardo dove la responsabilità è concreta.

La catena passa da due funzioni esposte

Il bollettino IBM descrive due problemi che diventano critici quando vengono concatenati. L’endpoint di accesso automatico `/api/v1/auto_login`, nelle configurazioni interessate, poteva rilasciare a qualunque chiamante di rete un bearer token con privilegi da superuser. Quel token consentiva poi di raggiungere `/api/v1/validate/code`, funzione pensata per controllare definizioni Python ma capace di eseguire codice durante la validazione. Non serve pubblicare un payload per capire la conseguenza: il confine di autenticazione viene superato prima che il validatore operi sul server.

IBM assegna alla vulnerabilità un punteggio CVSS 3.1 di 9,8 su 10 e specifica che decoratori, argomenti predefiniti e annotazioni Python possono essere valutati al momento della definizione della funzione. Il punteggio segnala gravità tecnica, ma l’elemento che cambia la priorità è l’evidenza di sfruttamento raccolta da CISA. Il catalogo non attribuisce pubblicamente una campagna ransomware e riporta quell’uso come sconosciuto: non è corretto aggiungere un gruppo, un obiettivo o un danno che le fonti non documentano.

Prima dell’aggiornamento: trovare ciò che è davvero acceso

La versione dichiarata in un file non basta. Bisogna controllare il pacchetto usato dal processo attivo, il tag e soprattutto il digest dell’immagine container, i pod o i nodi ancora in esecuzione e gli eventuali ambienti di test dimenticati. Un aggiornamento già preparato nel repository non protegge un container che non è stato ricreato. In un cluster, una sola replica rimasta alla 1.10.0 mantiene un punto vulnerabile anche se le altre mostrano la 1.10.1.

Va ricostruita anche l’esposizione reale: indirizzo pubblico, reverse proxy, bilanciatore, tunnel, port forwarding, accesso da VPN e reti interne. Un firewall host che sembra chiuso non esclude una pubblicazione effettuata dal runtime dei container o da un proxy a monte. L’inventario utile mette insieme nome dell’istanza, versione effettiva, percorso di accesso e dati o segreti a cui il processo può arrivare. È questo elenco, non la memoria del team, a stabilire l’ordine di intervento.

La 1.10.1 è la correzione, l’isolamento no

Il bollettino del fornitore non propone workaround: raccomanda di aggiornare subito Langflow OSS alla versione 1.10.1. In un deployment containerizzato significa recuperare l’immagine corretta, ricreare il servizio e verificare dall’istanza avviata versione e identificatore dell’immagine. In un’installazione Python occorre aggiornare il pacchetto nell’ambiente realmente usato dal servizio e riavviare il processo. Backup di configurazione e database vanno preparati secondo la procedura di ripristino dell’organizzazione, senza esporre ulteriormente copie della versione vulnerabile.

Se l’aggiornamento immediato è materialmente impossibile, togliere l’istanza da Internet, limitarne la raggiungibilità o fermarla riduce temporaneamente la superficie, ma non corregge il difetto. Anche una rete interna non è sinonimo di sicurezza: un account o un dispositivo già compromesso può raggiungere servizi che il pubblico non vede. La misura provvisoria deve quindi avere un responsabile e una scadenza breve, non diventare il motivo per rimandare indefinitamente la sostituzione.

Dopo il patch, controllare il periodo precedente

Aggiornare chiude il percorso noto per il futuro; non cancella un accesso eventualmente avvenuto prima. Se un’istanza dalla 1.0.0 alla 1.10.0 era raggiungibile, conviene preservare i log di applicazione, reverse proxy, sistema e piattaforma cloud prima che la rotazione li elimini. Fra i segnali da esaminare rientrano richieste inattese ai due endpoint citati dal bollettino, processi figli non previsti, nuovi file o attività pianificate e connessioni in uscita incompatibili con il normale profilo del servizio.

Un indizio non equivale automaticamente a una compromissione e l’assenza di una singola riga non prova il contrario, soprattutto se la registrazione era incompleta. Se emergono anomalie, è prudente coinvolgere il responsabile della sicurezza o la funzione di risposta agli incidenti prima di cancellare file o ricostruire la macchina. Le chiavi API, le credenziali del database e gli altri segreti accessibili al processo vanno ruotati in base alla valutazione del perimetro, conservando le evidenze necessarie.

La scadenza CISA non è una legge italiana

Nel catalogo KEV compare il 7 agosto come termine di intervento per le agenzie federali civili degli Stati Uniti. Non è una scadenza giuridica estesa alle imprese italiane. È però un segnale operativo utile ovunque: CISA aggiunge una voce quando dispone di evidenze di sfruttamento e di indicazioni chiare per mitigare. Anche l’agenzia coreana KISA, il 7 agosto, ha raccomandato agli utilizzatori delle versioni inferiori alla 1.10.1 di aggiornare. La geografia dell’avviso non limita la vulnerabilità tecnica.

La prova di chiusura da lasciare nel registro

Il lavoro si conclude con una verifica ripetibile: quali istanze esistevano, quali erano esposte, quale versione e digest eseguivano prima e dopo, quando sono state ricreate e quali log sono stati esaminati. È utile registrare anche il risultato dei controlli sui segreti e l’eventuale isolamento provvisorio. Una schermata con la scritta “aggiornato” non basta se non identifica il processo che serve il traffico reale.

Langflow collega spesso modelli, strumenti, API e fonti dati che valgono più dell’interfaccia stessa. Per questo una falla nel server di orchestrazione merita una risposta che unisca patch e verifica del passato. La regola pratica è semplice: se gestite Langflow OSS, trovate ogni istanza sotto la 1.10.1, aggiornatela e confermate che sia davvero quella in esecuzione; se era raggiungibile mentre risultava vulnerabile, trattate i log e i segreti come una seconda attività, non come un dettaglio facoltativo.