In breve
CVE-2026-49869 è un bypass dell’autenticazione con CVSS 10.0 in Kestra OSS che consegna a un attaccante non autenticato l’esecuzione di codice da remoto come root. L’eccezione prevista per l’endpoint pubblico di configurazione controlla solo la parte finale del percorso — endsWith("/configs") —, quindi qualsiasi richiesta il cui percorso termina con configs salta la Basic Auth. A quel punto l’attaccante può creare e avviare nel container worker un workflow con task shell o Python. La CISA l’ha inserita nel catalogo KEV il 2 settembre 2026.
Se Kestra è presente nella vostra pipeline di dati: aggiornate subito alla 1.3.21 o alla 1.0.45 e togliete da Internet ogni istanza esposta. Gli host di orchestrazione sono bersagli di grande valore proprio perché custodiscono le chiavi di tutto ciò che automatizzano — questo intervento ha la stessa priorità della vostra risposta agli incidenti in ambito cloud e DevOps.
In cosa consiste esattamente la falla
Kestra è un orchestratore open source guidato dagli eventi, usato per costruire e pianificare pipeline di dati e workflow di automazione — il tipo di strumento che lavora in silenzio al centro di una piattaforma dati e avvia tutto il resto. Come molti strumenti simili, viene distribuito con la Basic Auth attiva di default e con un unico endpoint pubblico, la configurazione dell’istanza, pensato per essere raggiungibile senza login. Il bug sta nel modo in cui questa eccezione viene applicata.
L’AuthenticationFilter decide se richiedere le credenziali chiamando request.getPath().endsWith("/configs"). È un confronto sul suffisso, non una corrispondenza esatta del percorso: non esenta solo l’endpoint /configs previsto, ma qualsiasi percorso API il cui ultimo segmento sia configs. All’attaccante basta aggiungere quel segmento a una route protetta per superare l’autenticazione. Una volta dentro, può creare un flow Kestra con task di script — shell, Python, Node, Bash — ed eseguirlo; questi task girano come root nel container worker Linux. È esecuzione di codice da remoto sull’host di orchestrazione, senza credenziali e senza interazione dell’utente.
L’advisory documenta anche una server-side request forgery secondaria: la funzione http() del motore di template Pebble non applica alcun filtro sugli URI, quindi un template costruito ad arte può chiamare servizi interni o l’endpoint dei metadati del cloud provider. Su un’istanza ospitata in cloud è una via diretta verso le credenziali dell’istanza e il movimento laterale. Il bypass con CVSS 10.0 fa notizia, ma è la SSRF a trasformare la compromissione di un singolo host in quella dell’intero ambiente.
Perché le piattaforme di orchestrazione vengono colpite di continuo
Non è un problema isolato di Kestra, ma l’ultimo di una serie di falle critiche nelle piattaforme di workflow e automazione. n8n, Langflow, MLflow e strumenti simili hanno avuto tutti, nell’ultimo anno, bug di RCE senza autenticazione o con bypass dell’autenticazione. Lo schema è strutturale: queste piattaforme esistono per eseguire codice arbitrario e raggiungere tutto ciò che automatizzano. Per progetto accumulano quindi credenziali dei database, chiavi cloud, token API e accesso alla rete interna. Una sola lacuna di autenticazione su un host del genere non significa un server compromesso, ma una testa di ponte verso le pipeline, i data warehouse e gli account cloud che ci stanno dietro.
Sono anche facili da lasciare esposte. Questi strumenti nascono come comodità interna, ricevono un URL pubblico per una demo veloce o per un collega in smart working e poi restano raggiungibili. «Esegue codice per progetto», «custodisce ogni segreto» e «a volte su Internet»: è esattamente il profilo che gli attaccanti cercano con le scansioni. Chiunque gestisca una piattaforma dati — in particolare i team che mettono in piedi rapidamente pipeline dati e ML — dovrebbe trattare ogni orchestratore e server di automazione come infrastruttura di primo livello, perché è così che lo trattano gli attaccanti.
Cosa significa per le aziende italiane
La conseguenza immediata è operativa: un inserimento nel KEV con un proof of concept pubblico significa che lo sfruttamento non è ipotetico, e le istanze non aggiornate raggiungibili da Internet vanno considerate compromesse. La scadenza della CISA vincola solo le agenzie federali statunitensi, ma il segnale — «viene usata negli attacchi adesso» — vale per tutti. Se non potete dimostrare che l’istanza Kestra era aggiornata prima di essere esposta, la postura corretta è la risposta agli incidenti, non il solo aggiornamento: ruotate i segreti e controllate i log.
Per le organizzazioni regolamentate c’è anche il tema della conformità. Con la NIS2, recepita in Italia dal D.Lgs. 138/2024, con il regolamento DORA per il settore finanziario o in un audit ISO 27001, una vulnerabilità nota e sfruttata su un sistema che tocca dati di produzione è esattamente il tipo di rilievo che auditor e autorità si aspettano di vedere individuato e corretto in tempi definiti. Se tramite un’istanza compromessa sono stati sottratti dati personali, l’articolo 33 del GDPR impone inoltre la notifica al Garante per la protezione dei dati personali entro 72 ore. Ne escono bene le organizzazioni che possono mostrare un inventario, uno storico delle patch e un registro della rotazione delle credenziali — non quelle che scoprono settimane dopo che lo strumento faceva parte del parco applicativo.
La lezione più ampia riguarda la catena di fornitura del software. La maggior parte dei team non ha scritto Kestra, ma si assume il rischio di farlo girare. L’infrastruttura open source in self-hosting scambia il vendor lock-in con il dovere di seguire gli advisory e di applicare le patch rapidamente. È un costo reale e va messo a budget: qualcuno deve essere responsabile dell’inventario di ciò che ospitate, iscriversi agli advisory di sicurezza e poter applicare una patch in poche ore quando un CVSS 10.0 finisce nel KEV.
Cosa fare subito
Se Kestra è presente nel vostro stack, l’ordine dei passaggi conta più dei singoli passaggi.
- Verificare se usate Kestra e in quale versione. Controllate immagini container, chart Helm e deployment in self-hosting; sono vulnerabili le release fino alla 1.3.20 inclusa.
- Aggiornare subito. Passate alla 1.3.21, alla 1.0.45 o a qualsiasi release 1.4.0+. Non esiste un workaround durevole che permetta di lasciare esposta una versione vulnerabile.
- Toglierla da Internet. Mettete ogni istanza esposta dietro una VPN o su una rete privata; un orchestratore non dovrebbe quasi mai essere raggiungibile direttamente dal web.
- Ruotare ogni segreto raggiungibile. Considerate esposte le credenziali dei database, le chiavi cloud e i token API che l’istanza poteva raggiungere, e ruotateli — con la SSRF sugli host cloud non è un passaggio facoltativo.
- Cercare tracce di abuso. Controllate i log per creazioni o esecuzioni di flow inattese e per richieste in uscita verso gli endpoint dei metadati, intorno e prima della data della patch.
- Inserirla nel monitoraggio degli advisory. Assicuratevi che questa e le altre piattaforme in self-hosting siano in un feed monitorato, così che il prossimo inserimento nel KEV non vi colga di sorpresa.
Questa non è una consulenza legale, e l’esposizione concreta dipende da come Kestra è distribuito da voi. Ma la direzione è inequivocabile: un bypass dell’autenticazione con CVSS 10.0 su un host che esegue codice e custodisce segreti, ora nel KEV, va corretto oggi — e i team che sanno già cosa ospitano lo chiudono in poche ore anziché in settimane.
Domande frequenti
Che cos’è la CVE-2026-49869 in Kestra?
Un bypass dell’autenticazione con CVSS 10.0 in Kestra OSS. L’AuthenticationFilter consente l’accesso all’endpoint pubblico di configurazione con un controllo sul suffisso, request.getPath().endsWith("/configs"), invece che con una corrispondenza esatta. Qualsiasi percorso API il cui ultimo segmento sia configs aggira quindi la Basic Auth: un attaccante non autenticato raggiunge gli endpoint protetti, crea un workflow con task di script e lo esegue come root nel container worker.
Quali versioni di Kestra sono vulnerabili e quali contengono la correzione?
Sono vulnerabili le release di Kestra OSS fino alla 1.3.20 inclusa con Basic Auth attiva, cioè la configurazione predefinita. La falla è corretta nelle versioni 1.0.45, 1.3.21 e in tutte le release dalla 1.4.0 in poi. L’aggiornamento è la misura principale; non esiste un workaround sicuro che lasci esposta una versione vulnerabile.
La CVE-2026-49869 viene sfruttata?
La CISA l’ha inserita nel catalogo KEV il 2 settembre 2026 – il segnale che esistono prove attendibili di sfruttamento attivo –, con scadenza al 5 settembre per le agenzie federali civili statunitensi. Esistono un proof of concept pubblico e uno scanner, quindi ogni istanza non aggiornata raggiungibile da Internet va considerata compromessa fino a prova contraria.
Cosa può fare un attaccante dopo lo sfruttamento?
Creare ed eseguire workflow Kestra con task shell, Python, Node o Bash, che girano come root nel container worker – esecuzione di codice da remoto completa sull’host di orchestrazione. Una SSRF secondaria tramite la funzione Pebble http(), priva di filtri sugli URI, può puntare ai metadati cloud o a servizi interni per rubare credenziali e muoversi lateralmente.
Quali obblighi di notifica possono scattare in Italia?
Se tramite un’istanza compromessa sono stati sottratti dati personali, l’articolo 33 del GDPR impone di notificare il Garante per la protezione dei dati personali entro 72 ore dalla scoperta. I soggetti che rientrano nella NIS2, recepita dal D.Lgs. 138/2024, hanno inoltre obblighi di notifica degli incidenti significativi verso il CSIRT Italia, e il settore finanziario quelli previsti da DORA. L’obbligo applicabile dipende da settore, dimensioni e dati coinvolti.
Cosa devono fare subito i team che usano Kestra?
Aggiornare immediatamente alla 1.3.21, alla 1.0.45 o alla 1.4.0+. Togliere da Internet ogni istanza esposta e metterla dietro una VPN. Ruotare credenziali, chiavi cloud e segreti raggiungibili dall’istanza. Poi controllare i log per creazioni o esecuzioni di workflow inattese intorno e prima della data della patch.
Fonti
Kestra — Advisory di sicurezza ufficiale GHSA-5vc5-wxxq-3fjx, CVE-2026-49869 (fonte primaria)
CISA — Known Exploited Vulnerabilities Catalog (fonte primaria)
LinuxSecurity — Kestra critical Linux container RCE flaw exploited, CISA warns