Il generatore di agenti AI che esegue il codice di chi passa: CVE-2026-0770 su Langflow

Uno strumento che esegue codice per progetto

Langflow serve a costruire, trascinando blocchi su una tela, i flussi e gli agenti che orchestrano modelli linguistici. Per farlo deve poter eseguire pezzi di logica scritti dall'utente: è parte del mestiere. Il problema nasce quando la porta d'ingresso a quell'esecuzione resta aperta a chiunque, senza il muro che dovrebbe separarla dal mondo.

È esattamente ciò che descrive CVE-2026-0770. La funzione che il nome promette essere un controllo — validate_code(), nel file src/lfx/src/lfx/custom/validate.py — invece di limitarsi a ispezionare il codice fornito lo passa direttamente a exec(), l'esecutore Python, senza alcuna sandbox. Ciò che doveva essere una validazione è, di fatto, un'esecuzione.

1. 01
   Richiesta all'endpoint /validate

   attaccante non autenticato
2. 02
   parametro exec_globals / validate_code()

   codice Python fornito dall'utente
3. 03
   exec() senza sandbox

   esecuzione arbitraria sul server

Perché il punteggio è quasi il massimo

La CVE porta un CVSS 9.8 (critico), e i due fattori che la spingono così in alto sono gli stessi che rendono una falla un incubo operativo: nessuna autenticazione richiesta e esecuzione di codice come risultato. Non serve un account, non serve un'interazione della vittima; basta raggiungere via rete un'istanza Langflow esposta e mandare una richiesta all'endpoint di validazione.

Il difetto rientra nella categoria «inclusione di funzionalità da una sfera di controllo non fidata»: il server accoglie ed esegue logica che arriva da fuori come se fosse propria. In pratica, per l'attaccante, l'endpoint di validazione diventa una shell.

Sfruttata davvero, non solo teorica

Il 21 luglio 2026 CISA ha aggiunto CVE-2026-0770 al catalogo delle vulnerabilità note sfruttate (KEV), nello stesso batch di quattro che comprendeva anche le due falle di WordPress Core. L'ingresso in KEV è il segnale che conta: non è una CVE «potenzialmente pericolosa», è una CVE che qualcuno sta usando.

A complicare il quadro, per questa falla sono già disponibili più proof-of-concept pubblici su GitHub. Quando l'exploit è a portata di clone e il bersaglio è uno strumento pensato per prototipare in fretta — quindi spesso installato al volo, magari lasciato raggiungibile senza un reverse proxy che autentichi a monte — la barriera pratica per un attaccante opportunistico crolla.

Va detto con onestà ciò che non è confermato: non c'è un gruppo attribuito né una campagna nominata. Lo scenario coerente è quello dello sfruttamento opportunistico delle istanze esposte, non un'operazione mirata. Le versioni esatte affette e il numero di istanze colpite vanno letti sulle fonti primarie (l'advisory GitHub e i tracker CVE) man mano che si consolidano, non dati per definitivi qui.

Cosa fare

Tre mosse, in ordine di urgenza. Primo: aggiornare Langflow alla versione che rimuove l'esecuzione non protetta, seguendo l'advisory ufficiale (GHSA-g22f-v6f7-2hrh) per la versione corretta. Secondo, e spesso più importante del primo nell'immediato: togliere l'istanza dall'esposizione diretta su internet. Uno strumento di sviluppo come questo non ha ragione di essere pubblicamente raggiungibile; metterlo dietro una VPN o un proxy che autentica riduce la superficie a prescindere dalla patch. Terzo: sulle istanze che potrebbero essere state raggiunte, cercare segni di esecuzione anomala — processi Python inattesi, connessioni in uscita, file lasciati sul sistema — perché con una RCE non autenticata già in KEV, l'ipotesi di lavoro prudente è che un'istanza esposta e non aggiornata sia da considerare compromessa fino a prova contraria.