Langflow CVE-2026-0768: la dodicesima vulnerabilità di Langflow sfruttata attivamente quest'anno

CVE-2026-0768 è una vulnerabilità di esecuzione remota di codice non autenticata in Langflow, il framework visuale open source per assemblare pipeline e agenti di modelli linguistici di grandi dimensioni, e gli attaccanti la stavano sfruttando attivamente entro la fine di agosto 2026. La falla risiede nel validatore di codice dietro l'editor di componenti personalizzati di Langflow: l'endpoint validate accetta un parametro code ed esegue il Python che contiene, senza autenticazione e, secondo la formulazione della Zero Day Initiative, «nel contesto di root». La rete di honeypot Canary di VulnCheck ha registrato più di 50 tentativi di sfruttamento entro poche ore dalle prime rilevazioni del 30 agosto 2026, e più di 360 entro lunedì 1 settembre, tutti contro sensori nel Regno Unito; Caitlin Condon di VulnCheck ha affermato che il traffico di origine proveniva principalmente dalla Russia. Le richieste non erano ransomware. Leggevano variabili d'ambiente contenenti credenziali superuser di Langflow, chiavi API OpenAI e chiavi di accesso e segrete AWS, per poi cercare in /root/.cache/langflow/secret_key, .ssh e .bash_history. La voce completa dell'archivio per questo incidente, comprese le classificazioni di gravità, confidenza e danno, si trova all'interno dell'Orca AI Incident Archive, insieme agli altri record di furto di credenziali e di infrastruttura AI che lo circondano.

Security Affairs ha pubblicato il suo resoconto il 2 settembre 2026; Ionut Arghire di SecurityWeek ha riportato lo sfruttamento il giorno prima, Bill Toulas di BleepingComputer ne ha parlato quella settimana, e l'AI Safety Initiative della Cloud Security Alliance ha fatto seguito il 4 settembre con una nota di ricerca che ribadisce il meccanismo e aggiunge raccomandazioni. Nessuno dei resoconti esaminati per questo articolo ha indicato un'organizzazione compromessa. Tutto risale ai sensori di VulnCheck e all'avviso pubblicato dalla Zero Day Initiative a gennaio.

Un editor che esegue ciò che gli viene chiesto di validare

Il punto di forza di Langflow è che si assembla un'applicazione AI trascinando componenti su un canvas. I componenti personalizzati sono in Python: l'editor consente a un utente di incollare codice e premere validate, e il server lo verifica. Secondo il bollettino ZDI ZDI-26-034, tale verifica esegue il codice. La frase sulla causa radice nel bollettino è una riga — "la mancanza di una corretta validazione di una stringa fornita dall'utente prima di usarla per eseguire codice Python" — e il risultato è che una singola richiesta HTTP non autenticata esegue Python arbitrario sull'host.

Tre proprietà trasformano ciò in un incidente anziché in una segnalazione di bug. Il vettore CVSS è AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H, con punteggio 9.8: raggiungibile tramite la rete, bassa complessità, nessun privilegio, nessuna interazione dell’utente e perdita totale di riservatezza, integrità e disponibilità. Il contesto di esecuzione è root, motivo per cui i comandi dell’attaccante che Condon e la Cloud Security Alliance descrivono entrambi puntano a /root/.cache/langflow/secret_key — il file che Langflow usa per crittografare le credenziali memorizzate e i dati di sessione. E l’endpoint non richiede alcuna credenziale, quindi l’esposizione è funzione della sola raggiungibilità.

La cronologia della divulgazione è importante per capire come si sono svolti i fatti. La timeline di ZDI registra che la segnalazione è arrivata all'account GitHub di Langflow il 18 luglio 2025, una richiesta di aggiornamenti l'11 settembre 2025, una richiesta della correzione il 10 ottobre 2025 e una comunicazione dell'intenzione di pubblicare come zero-day il 10 dicembre 2025. ZDI ha pubblicato l'avviso il 9 gennaio 2026. I ricercatori accreditati sono Peter Girnus, William Gamazo Sanchez e Alfredo Oliveira di Trend Research. Il database degli avvisi di GitHub contiene lo stesso testo di GHSA-x5pr-rvjj-j6qm, pubblicato il 23 gennaio 2026, classificato CWE-94, e non elenca alcun intervallo di versioni interessate. La mitigazione dichiarata da ZDI non è una patch: consiste nel "limitare l'interazione con il prodotto".

Le segnalazioni pubbliche collocano l'intervallo interessato nelle release di Langflow fino alla 1.4.2 inclusa, la versione rispetto alla quale è stato realizzato e testato il modulo Metasploit aggiunto in seguito. Qui terminano le certezze, e la sezione sulle correzioni riportata di seguito spiega perché.

Cosa stabiliscono e cosa non stabiliscono i rilevamenti 360

I Canaries di VulnCheck sono sensori esposti su Internet, progettati per apparire come ciò che un attaccante sta cercando con le proprie scansioni. L'azienda ha osservato il primo sfruttamento di CVE-2026-0768 il 29–30 agosto 2026: più di 50 rilevamenti nel giro di poche ore la domenica, saliti oltre 360 entro il lunedì. Condon, vicepresidente della threat research di VulnCheck, ha descritto l'attività su LinkedIn come «un misto di ricognizione e raccolta di credenziali», aggiungendo che il traffico di origine proveniva principalmente dalla Russia e aveva «finora colpito esclusivamente i Canaries nel Regno Unito».

La sequenza di comandi catturata dai sensori è sufficientemente specifica da costituire un playbook. Gli attaccanti hanno interrogato l'ambiente alla ricerca di LANGFLOW_SUPERUSER, di variabili corrispondenti a OPENAI_API e di chiavi AWS_ACCESS e AWS_SECRET — le tre famiglie di credenziali che è più probabile che un host Langflow contenga. Hanno letto la chiave segreta memorizzata nella cache in /root/.cache/langflow/secret_key. Hanno verificato l'accesso a .ssh e ispezionato la dimensione di .bash_history, entrambi indicatori della capacità di un operatore di muoversi lateralmente anziché limitarsi a leggere segreti. Un resoconto della community sulla catena, citato dalla Cloud Security Alliance, aggiunge che la stessa attività ha cercato segreti incorporati negli alberi dei sorgenti e nei file .env, ha esfiltrato ciò che ha trovato e ha verificato se un host fosse già stato compromesso con una backdoor da un operatore precedente prima di aggiungere la propria persistenza.

Ciò che questo stabilisce è che l'exploit funziona, che è stato utilizzato contro istanze Langflow esposte a Internet e che l'obiettivo erano le credenziali anziché il danneggiamento. Ciò che non stabilisce è una vittima. I canary sono esche; un rilevamento è una richiesta, non un furto confermato. L'archivio classifica questo record come danno reale, e il danno documentato nelle fonti pubbliche è l'esecuzione confermata di codice per la raccolta di credenziali contro sistemi esposti — non un'organizzazione nominata le cui chiavi siano state utilizzate.

Un dettaglio contraddice la versione abituale sulla divulgazione. Secondo VulnCheck, quando è iniziato lo sfruttamento non esisteva alcun proof-of-concept pubblico per CVE-2026-0768. L'avviso era pubblico da quasi otto mesi e descriveva la vulnerabilità in modo abbastanza preciso da permettere a qualcuno di costruire un exploit partendo dal testo. L'interpretazione dell'azienda, come riportato da The Hacker News, è che si sia trattato di un'elaborazione indipendente anziché del riutilizzo di codice trapelato.

Dodici difetti, quindicimila tentativi — e dove quei numeri si piegano

La statistica che dà peso a questo incidente proviene da {{1}}VulnCheck{{/1}}, e vale la pena citarla con le parole stesse dell'azienda anziché parafrasarla. "{{2}}Prima del 2026, le evidenze mostravano solo una vulnerabilità di Langflow nota per essere sfruttata attivamente,{{/2}}" ha affermato. "{{3}}Nel 2026, le cose sono cambiate rapidamente.{{/3}}" {{4}}SecurityWeek{{/4}} riferisce che VulnCheck sta monitorando "{{5}}11 ulteriori vulnerabilità prese di mira e segnalate come sfruttate attivamente{{/5}}" nel corso del 2026.

Aggiungile e ottieni dodici vulnerabilità Langflow sfruttate, una delle quali precede l'anno. Non è la stessa cosa di dodici nel 2026, e le fonti oscillano tra le due formulazioni. Il titolo di Forkast definisce CVE-2026-0768 "la dodicesima CVE sfruttata di Langflow nel 2026", mentre il corpo dello stesso articolo descrive la dozzina come "11 nuove vulnerabilità e una individuata prima dell'inizio dell'anno". Il titolo della scheda segue quello dell'articolo. A una lettura rigorosa, il 2026 ne conta undici su dodici, mentre la dodicesima — quella nota prima di quest'anno — costituisce il resto.

Il dato di 15.000 ha un margine comparabile. SecurityWeek, The Hacker News e Forkast attribuiscono tutti "oltre 15.000 attacchi riusciti" a tre vulnerabilità nominate: CVE-2026-0769, CVE-2025-3248 e CVE-2026-5027. È un numero elevato, ma è un conteggio relativo a tre CVE, non all'intero portafoglio 2026 di Langflow. Formularlo come tentativi di sfruttamento contro il portafoglio — come fa il riepilogo dell'archivio — è più ampio di quanto pubblicato da VulnCheck.

Le singole voci alla base di questo schema sono documentate. CVE-2025-3248 era una vulnerabilità di code injection nello stesso endpoint /api/v1/validate/code, corretta in Langflow 1.3.0 sostituendo l'esecuzione con una validazione in sola compilazione, secondo l'advisory GitHub GHSA-rvqx-wpfh-mfx7 citato dalla Cloud Security Alliance — il che significa che CVE-2026-0768 è la stessa classe di bug nello stesso percorso di codice, circa quattro mesi dopo il rilascio di quella correzione. CVE-2026-33017, un RCE non autenticato nell'endpoint pubblico di build dei flow, è stato trasformato in un'arma entro circa 20 ore dalla sua divulgazione nel marzo 2026 e usato per sottrarre credenziali OpenAI, Anthropic e AWS prima di passare al cryptomining di Monero, secondo il resoconto della Cloud Security Alliance. La nota della stessa alleanza del 12 giugno 2026 riguarda CVE-2026-5027, una vulnerabilità di path traversal nell'endpoint di caricamento file che i ricercatori hanno collegato al gruppo MuddyWater, sponsorizzato dallo Stato iraniano, e la sua nota del 4 settembre registra CVE-2026-55255, un bypass dell'autorizzazione che consente a un utente autenticato di eseguire i flow di un altro utente, inserito nel catalogo Known Exploited Vulnerabilities della CISA il 7 luglio 2026. Queste quattro condividono un profilo comune: un endpoint che ha omesso l'autenticazione o la sanitizzazione, in una piattaforma il cui compito è custodire le credenziali per tutto ciò con cui comunica.

Perché una piattaforma di orchestrazione vale la pena

Un'istanza Langflow di produzione è configurata con chiavi API dei provider, credenziali cloud, stringhe di connessione al database e segreti di integrazione, perché i flussi che esegue ne hanno bisogno al momento della chiamata. La compromissione dell'host garantisce quindi accesso funzionante a ogni servizio le cui credenziali sono archiviate dall'istanza. Chiavi OpenAI o Anthropic rubate consentono a un attaccante di addebitare l'inferenza alla vittima o di impersonare l'organizzazione a valle; chiavi AWS rubate aprono l'infrastruttura ben oltre il container Langflow. È questa leva, più che qualsiasi capacità specifica dell'IA, che i comandi osservati stavano cercando di sfruttare.

Il giudizio della Cloud Security Alliance è che la ricorrenza in quattro diversi sottosistemi di Langflow in un solo anno — validatore del codice, endpoint pubblico di build dei flow, caricamento di file, esecuzione dei workflow — indichi una lacuna sistemica nell'ingegneria della sicurezza anziché una serie di difetti non correlati. Questa è la valutazione dell'alleanza, offerta in una nota di ricerca, non una conclusione di un revisore indipendente, e Langflow non ha risposto pubblicamente a essa nel materiale esaminato qui.

Cosa è stato corretto e cosa è ancora ambiguo

Questa è la parte più debole della documentazione pubblica, e vale la pena essere precisi sul perché. L'avviso di ZDI non indica alcuna versione corretta. La voce del database Snyk per la CVE elenca come versioni interessate tutte quelle precedenti alla 1.10.1 e raccomanda di aggiornare alla 1.10.1 o a una versione successiva. I resoconti pubblici, inclusi SecurityWeek e Security Affairs, descrivono l'intervallo interessato come le release fino alla 1.4.2, ma non identificano alcuna release corretta. Il Cloud Security Alliance ha osservato il 4 settembre che i manutentori di Langflow non avevano pubblicato un avviso di sicurezza dedicato che menzionasse questa CVE, e che i tracker non concordavano su quale release l'avesse effettivamente risolta — un'ambiguità che, secondo l'alleanza, riecheggia un precedente caso Langflow in cui una versione indicata come corretta rimaneva sfruttabile.

Langflow ha effettivamente pubblicato correzioni nell'area giusta, nel giorno giusto. La versione 1.11.6 è stata pubblicata il 1° settembre 2026, il lunedì in cui il conteggio degli honeypot ha superato 360, e le sue note di rilascio descrivono un backport di correzioni di sicurezza tra cui «close component code scan gaps» e «resolve annotations without execution» (pull request 14876). La versione 1.12.0 è seguita quella sera. Un ulteriore hardening dello stesso percorso di codice è proseguito in seguito: una pull request successiva intitolata «stop validate_code from executing imports» indica che l'endpoint di validazione veniva ancora rafforzato settimane dopo il primo sfruttamento. Niente di tutto ciò costituisce una dichiarazione del fornitore secondo cui CVE-2026-0768 è corretto in una versione denominata, e nessuna è stata trovata nelle fonti citate del record.

Ciò che è cambiato dal lato degli attaccanti è più chiaro. Un modulo di exploit Metasploit per la vulnerabilità è stato aperto come pull request il 2 settembre 2026 — lo stesso giorno in cui ha pubblicato Security Affairs — e integrato l'8 ottobre 2026, testato contro Langflow 1.4.2. Qualunque fosse lo stato della derivazione originale, sfruttare questa vulnerabilità ha smesso di richiedere lavoro originale sei settimane dopo che se ne è iniziato lo sfruttamento.

La risposta raccomandata dalla Cloud Security Alliance è una sequenza di patch-and-rotate anziché una semplice patch: verificare la versione in esecuzione e passare alla release stabile corrente; considerare compromessa qualsiasi istanza esposta a Internet su una versione interessata fino a prova contraria, poiché l’attività osservata è una raccolta silenziosa anziché un’interruzione visibile; e ruotare ogni segreto a cui l’istanza potrebbe avere accesso — la password del superuser di Langflow, le chiavi API dei provider, le chiavi di accesso e segrete AWS e la stessa chiave segreta di Langflow, ricifrando le credenziali memorizzate anziché limitarsi a sostituire il file. Raccomanda inoltre di controllare i log di accesso per richieste all’endpoint validate, verificare authorized_keys per chiavi SSH sconosciute e cercare prove che un precedente operatore avesse già inserito una backdoor sull’host. Laddove la piattaforma deve rimanere raggiungibile, suggerisce di limitare l’accesso o disabilitare l’endpoint validate e di abbandonare le chiavi a lunga durata e con privilegi elevati memorizzate direttamente nella piattaforma.

Accertato, riferito e non accertato

Accertato: che CVE-2026-0768 è una RCE non autenticata nell'endpoint validate di Langflow che esegue Python come root, documentata in ZDI-26-034 e replicata come GHSA-x5pr-rvjj-j6qm; che lo sfruttamento è iniziato il 29–30 agosto 2026; che VulnCheck ha registrato più di 50 rilevamenti nel giro di poche ore e più di 360 entro il 1° settembre, contro sensori nel Regno Unito, con traffico proveniente principalmente dalla Russia; e che le richieste osservate erano dirette a credenziali superuser di Langflow, OpenAI e AWS, oltre alla chiave segreta memorizzata in cache, .ssh e .bash_history. Queste informazioni provengono dall'avviso stesso e dalla telemetria di VulnCheck, come riportato in modo indipendente da SecurityWeek, Security Affairs e The Hacker News.

Riportato, non verificato in modo indipendente: ogni conteggio delle rilevazioni. I 50, i 360 e i 15,000 sono dati di VulnCheck stesso, pubblicati dall'azienda e ripetuti da testate che la citano; nessuna seconda rete honeypot ha pubblicato un conteggio di conferma. L'attribuzione all'infrastruttura russa è parimenti una lettura di VulnCheck del traffico di origine, non una valutazione che alcun governo o CERT abbia avallato nel materiale esaminato.

Non è accertato: che alcuna organizzazione nominata abbia perso credenziali. Nessuna vittima è stata identificata nelle fonti del record. Né esiste una versione corretta confermata: ZDI non ne indica nessuna, Snyk dice 1.10.1, le segnalazioni indicano che le versioni interessate arrivano alla 1.4.2, e le note di rilascio della 1.11.6 descrivono correzioni di sicurezza senza collegarle a questa CVE. Né il conteggio della "dodicesima falla del 2026" è coerente al suo interno tra le sue stesse fonti, come illustrato sopra.

La parte che dovrebbe preoccupare chi applica le patch secondo una pianificazione

Il divario di otto mesi è la scoperta. CVE-2026-0768 è stato pubblicato come zero-day il 9 gennaio 2026, con una descrizione tecnica sufficientemente dettagliata da consentire di ricostruirlo, e non si è registrato nulla sui sensori di VulnCheck fino all'ultimo fine settimana di agosto. Poi sono arrivati diverse centinaia di tentativi in tre giorni, da operatori che, secondo il resoconto dell'azienda, non avevano alcun exploit pubblico da copiare. Qualunque cosa abbia mantenuto quelle istanze non patchate per otto mesi di un avviso critico pubblico è la stessa cosa che ha reso la falla degna di essere sfruttata quando qualcuno alla fine ha scritto il codice.

Chiude anche un cerchio aperto dalle precedenti CVE di Langflow. CVE-2025-3248 è stata corretta rimuovendo l'esecuzione dallo stesso percorso di convalida; CVE-2026-0768 viene comunque eseguita su quel percorso. Una correzione che rimuove un comportamento senza rimuovere la decisione progettuale che lo ha prodotto fa guadagnare tempo, e in questo caso ne ha fatto guadagnare circa quattro mesi.