VulnCheck ha registrato tra il 30 agosto e il 31 agosto 2026 l'inizio dello sfruttamento in rete di due vulnerabilità critiche molto diverse fra loro, ma accomunate da un dettaglio che le rende pericolose: entrambe colpiscono componenti che nessuno considera "esposti" finché non lo sono.

La prima è CVE-2026-0768 (CVSS 9.8) in Langflow, la piattaforma open source per costruire flussi applicativi basati su LLM. La seconda è CVE-2026-66066, battezzata KindaRails2Shell (CVSS 9.5), in Ruby on Rails. Oltre 50 rilevazioni nelle prime ore del 30 agosto sui sensori di VulnCheck, salite a 360 nel giro di un weekend.

Langflow: esecuzione di codice come root, senza autenticazione

CVE-2026-0768 nasce dalla mancata validazione di un parametro passato all'endpoint validate dell'editor dei componenti personalizzati. Un attaccante non autenticato può far eseguire codice Python arbitrario nel contesto dell'utente root.

Il traffico osservato non è ancora, in prevalenza, distruttivo: è ricognizione e furto di credenziali. Le richieste degli attaccanti interrogano variabili d'ambiente come LANGFLOW_SUPERUSER, OPENAI_API*, AWS_ACCESS* e AWS_SECRET*, leggono /root/.cache/langflow/secret_key, verificano l'accesso a .ssh e la dimensione di .bash_history. Secondo Caitlin Condon di VulnCheck il traffico proviene principalmente dalla Russia e finora ha colpito esclusivamente sensori nel Regno Unito.

Non è un episodio isolato: Langflow è ormai un bersaglio ricorrente. VulnCheck conta almeno 12 vulnerabilità sfruttate dal 2025 nello stack degli strumenti per lo sviluppo AI, con oltre 15.000 tentativi riusciti concentrati su CVE-2026-0769, CVE-2025-3248 e CVE-2026-5027. In un caso osservato, l'attaccante ha usato CVE-2026-5027 per installare un raccoglitore di credenziali in Python, agenti proxy e SimpleHelp per l'accesso remoto. In un altro ha arruolato la macchina in una botnet di mining Monero, ha disattivato auditd creando un punto cieco forense e ha sfruttato CVE-2026-0769 per rilasciare un binario chiamato .sysd, per poi ripartire a scansionare altri bersagli.

KindaRails2Shell: la patch non chiude tutto

CVE-2026-66066 è tecnicamente più interessante, e più insidiosa. Un'applicazione è vulnerabile quando usa Active Storage con il processore vips per generare le varianti delle immagini e accetta upload da utenti non fidati — cioè la configurazione predefinita di moltissime applicazioni Rails.

L'attacco sfrutta la discrepanza fra come Active Storage e libvips interpretano lo stesso file. L'attaccante carica un file etichettato come MATLAB Level 5: libvips lo passa al loader MATLAB, che lo consegna a libmatio, che lo riconosce come MAT 7.3 e lo affida a HDF5. La funzione External File List di HDF5 consente a un dataset di referenziare file esterni, e a quel punto l'"immagine" legge file arbitrari dal server.

Il bottino tipico è il contenuto dell'ambiente del processo Rails: secret_key_base, la master key, le password del database, le credenziali dello storage cloud, i token API. Con secret_key_base in mano si firmano cookie e payload validi, e da lì si arriva all'esecuzione di codice.

Rails ha corretto il 29 luglio 2026 con le versioni 7.2.3.2, 8.0.5.1 e 8.1.3.1. Qui però arriva il dettaglio che va letto con attenzione: VulnCheck ha testato un server già aggiornato a 8.1.3.1 e ha riscontrato che la patch blocca la lettura dei file via libvips ma non neutralizza la deserializzazione Marshal della variation key. Il gadget di esecuzione codice continua a funzionare su un server patchato, a condizione che l'attaccante disponga di una firma valida — quindi di una secret_key_base compromessa. All'inizio di agosto erano oltre 7.100 le istanze Rails vulnerabili esposte su Internet. Lo sfruttamento osservato ha colpito sensori a Singapore, in Israele e nel Regno Unito, con traffico proveniente da un singolo indirizzo IP in Francia e comando e controllo verso un host israeliano.

Cosa significa per le aziende italiane

Ci sono due lezioni distinte, e la seconda è quella che di solito viene ignorata.

Le piattaforme AI sono infrastruttura di produzione, non laboratori. Langflow, come gli strumenti simili, nasce come ambiente di prototipazione: si installa in fretta, spesso su una VM cloud di reparto, spesso senza passare dal team di sicurezza. Il problema è che quella stessa istanza contiene chiavi OpenAI, credenziali AWS, connessioni a database interni. È esattamente il profilo di macchina che nessuno inventaria e che nessuno patcha. In molte organizzazioni italiane l'adozione di questi strumenti è partita dal basso, nel 2025-2026, senza governance: il primo passo concreto non è applicare una patch, è scoprire quante di queste istanze esistono e chi le ha esposte. Un'istanza Langflow raggiungibile da Internet è, di fatto, un contenitore di segreti in chiaro con una RCE non autenticata davanti.

"Abbiamo patchato" non è una risposta completa. Il caso Rails mostra un pattern che si ripete sempre più spesso: la correzione chiude il vettore di ingresso ma non revoca l'effetto di un'eventuale compromissione già avvenuta. Se un attaccante ha esfiltrato secret_key_base prima dell'aggiornamento, la patch non gli toglie nulla. La domanda corretta dopo un aggiornamento di sicurezza non è "siamo alla versione giusta?" ma "i segreti che quella vulnerabilità poteva leggere sono stati ruotati?". Vale per Rails come per ogni falla che espone credenziali.

Sul piano normativo, per un'organizzazione soggetta a NIS2 una compromissione di questo tipo può integrare un incidente significativo, con notifica al CSIRT Italia entro 24 ore per il preallarme e 72 ore per la notifica completa. Se dall'istanza compromessa erano raggiungibili dati personali — e con credenziali di database e storage cloud spesso lo sono — scatta anche la valutazione ex art. 33 GDPR per la notifica al Garante entro 72 ore. Chi sviluppa e vende software basato su questi componenti deve inoltre considerare che dall'11 settembre 2026 il Cyber Resilience Act impone al fabbricante la segnalazione delle vulnerabilità attivamente sfruttate nei propri prodotti.

Cosa fare subito

  • Aggiornare Langflow all'ultima versione disponibile e verificare che l'istanza non sia raggiungibile da Internet. Se serve accesso remoto, metterla dietro VPN o reverse proxy autenticato.
  • Cercare le istanze Langflow non censite in cloud e on-premise: scansione interna sulle porte tipiche del servizio e controllo dei gruppi di sicurezza che espongono porte applicative verso 0.0.0.0/0.
  • Aggiornare Rails a 7.2.3.2, 8.0.5.1 o 8.1.3.1 secondo il ramo in uso.
  • Ruotare tutti i segreti delle applicazioni Rails potenzialmente esposte: secret_key_base, master key, credenziali database, chiavi dello storage cloud, token API. Questo passaggio è indispensabile anche dopo la patch.
  • Valutare la disattivazione dei loader libvips non necessari o l'imposizione di un allow-list dei formati accettati in upload, invece di affidarsi al rilevamento automatico del tipo di file.
  • Verificare l'integrità del logging sulle macchine esposte: la disattivazione di auditd osservata negli attacchi a Langflow è pensata proprio per impedire la ricostruzione a posteriori.
  • Cercare indicatori di compromissione: connessioni in uscita anomale, processi con nomi mascherati (come il .sysd osservato), utilizzo di CPU compatibile con il mining, presenza di SimpleHelp o di agenti di accesso remoto non autorizzati.
  • Trattare le chiavi API dei modelli AI come credenziali privilegiate: rotazione periodica, limiti di spesa e monitoraggio dell'uso anomalo.