28 marzo 2026 · 7 min lettura
Intelligenza ArtificialeOracle licenzia 18% del personale per finanziare $50 miliardi in AI. In Italia il tribunale di Roma legittima il licenziamento in contesto AI. Cosa significa per chi gestisce infrastruttura in autonomia.
Intelligenza Artificialeduck.ai promette chat AI senza tracciamento: nessun log, nessun IP, accordi con Anthropic e OpenAI. Ma DuckDuckGo ha già tradito questa fiducia una volta.
Iscriviti alla newsletter per ricevere i migliori articoli direttamente nella tua inbox.
La cloud sovranità europea è sovereignty washing: i datacenter sono in UE, le chiavi restano a Seattle. Gaia-X è fallito, NIS2 stringe. Il homelab risponde.
Langflow ha regalato agli attaccanti un endpoint pubblico che accetta codice Python arbitrario e lo esegue con exec() senza autenticazione, senza sandbox, senza nemmeno la decenza di fingere un controllo. La CVE-2026-33017, CVSS v4 9.3 (v3.1: 9.8), ha trasformato ogni istanza esposta di Langflow in una shell remota raggiungibile con una singola richiesta POST. Venti ore dopo la disclosure, senza proof-of-concept pubblico, qualcuno aveva già un exploit funzionante. Se pensi che sia un incidente isolato, sappi che è la seconda volta che Langflow cade sullo stesso identico pattern. Chi ha seguito la supply chain attack su LiteLLM sa che l'ecosistema AI open-source sta collezionando figuracce a ritmo industriale.
La catena è brutale nella sua semplicità. L'endpoint /api/v1/build_public_tmp/{flow_id}/flow accetta una richiesta POST con codice Python nel payload. Quel codice attraversa start_flow_build(), arriva a prepare_global_scope() e finisce dritto dentro exec(compiled_code, exec_globals) alla riga 397 di validate.py. Nessun token, nessun header di autenticazione, nessuna whitelist di operazioni. Una piattaforma con ~145.000 stelle GitHub e oltre 15 milioni di download che espone un interprete Python completo a chiunque sappia scrivere un curl.
# Esempio sanitizzato — struttura della richiesta che sfrutta l'endpoint vulnerabile
curl -X POST \
http://TARGET:7860/api/v1/build_public_tmp/FLOW_ID/flow \
-H 'Content-Type: application/json' \
-d '{"code": "__import__(\"os\").system(\"id\")"}' # RCE non autenticataNon serve reverse engineering sofisticato. Non serve un exploit chain multi-step. Un attaccante con competenze base e un terminale può estrarre chiavi API OpenAI, credenziali AWS, connection string di database, file .env — tutto ciò che il processo Langflow riesce a leggere sul filesystem.
Il 17 marzo 2026 alle 20:05 UTC l'advisory diventa pubblico. Il 18 marzo alle 16:04 UTC il primo exploit in-the-wild è già in circolazione. Venti ore senza PoC pubblico — gli attaccanti hanno costruito l'exploit partendo dal solo testo dell'advisory. Questo dato va messo nel contesto: il median time-to-exploit è collassato da 771 giorni nel 2018 a poche ore nel 2024-2026 — già nel 2023, il 44% delle vulnerabilità note veniva weaponizzato entro 24 ore dalla disclosure.
"Il passaggio da timeline di sfruttamento di mesi a weaponizzazione nello stesso giorno rappresenta un cambio strutturale" — Sysdig TRT
Chi gestisce un homelab con servizi AI esposti — e chi ha letto del worm GlassWorm su VS Code conosce il pattern — deve accettare una realtà scomoda: il tempo tra "esce la patch" e "sei bucato" si misura in ore, non in sprint di pianificazione.
Ecco la parte che trasforma una vulnerabilità grave in uno scandalo. Nel 2025, la CVE-2025-3248 (CVSS 9.8) aveva colpito /api/v1/validate/code — stesso root cause: codice utente passato a exec() senza sandbox. La fix? Aggiungere autenticazione davanti all'endpoint. Il problema di fondo — un interprete Python esposto senza isolamento — è rimasto lì, intatto, come un ordigno inesploso in mezzo al codebase.
Il ricercatore Aviral Srivastava (Security Engineer, Amazon) ha scoperto la CVE-2026-33017 il 25 febbraio 2026 con un metodo che dovrebbe far riflettere ogni maintainer open-source: ha analizzato il diff della patch precedente e ha cercato lo stesso pattern altrove nel codebase. Riproducibilità: 100%.
"Quando audito un codebase, parto da ciò che è già stato fixato. Le patch ti dicono cosa gli sviluppatori considerano una vulnerabilità" — Aviral Srivastava, Security Engineer
Consiglio elementare, eppure evidentemente troppo ambizioso per un progetto da 145.000 stelle. La storia completa delle CVE Langflow è un crescendo:
Quattro CVE critiche in un anno. Tutte sopra 9.0. Chi ancora si fida del ciclo di rilascio di Langflow ha un problema di valutazione del rischio, non di ottimismo.
Il colpo di grazia alla credibilità arriva da JFrog. I ricercatori hanno verificato la versione 1.8.2 — quella indicata come fix — e hanno scoperto che era ancora vulnerabile. Il fix reale è arrivato solo con langflow-nightly 1.9.0.dev18, una nightly build che nessun ambiente di produzione sano di mente dovrebbe eseguire.
"La sicurezza non può essere determinata solo da ciò che le fonti esterne dichiarano, ma solo verificando come il codice si comporta nella pratica" — JFrog Security Research
Tradotto: non fidarti del changelog, leggi il codice. Un principio ovvio che diventa urgente quando i maintainer dichiarano "fixato" qualcosa che non lo è. Chi si è sentito al sicuro dopo aver aggiornato alla 1.8.2 ha continuato a esporre un interprete Python remoto per settimane. Un pattern che ricorda le vulnerabilità CrackArmor di AppArmor — fix parziali che creano un falso senso di sicurezza peggiore della falla originale.
Gli attaccanti non si sono accontentati di dimostrare la vulnerabilità. Hanno estratto ciò che ogni istanza Langflow custodisce: chiavi API OpenAI, Anthropic e AWS, database connection string, file .env completi. Il Cloud Security Alliance lo ha detto senza giri di parole:
"Una singola istanza Langflow compromessa non è semplicemente una violazione server: è un potenziale punto di ingresso verso ogni credenziale di servizio AI connesso, account cloud e database" — CSA Labs
Nel contesto homelab il danno è ancora più concentrato. Chi fa girare Langflow su Docker con la configurazione default ha LANGFLOW_AUTO_LOGIN=true — una bomba a orologeria che elimina anche il blando ostacolo dell'autenticazione. Se il container è esposto via Cloudflare Tunnel, reverse proxy o port forwarding, eri raggiungibile. Se non hai segmentato la rete, all'attaccante basta un lateral movement per raggiungere il tuo intero homelab Proxmox.
Puntare il dito solo contro Langflow è comodo ma intellettualmente disonesto. Il pattern exec()/eval() senza sandbox è endemico nell'ecosistema AI workflow:
L'OWASP Top 10 Agentic AI 2026 lo ha codificato come rischio strutturale: "Un agente che genera codice e lo esegue in un ambiente non sandboxato offre agli attaccanti un percorso diretto verso l'esecuzione di codice remoto sulla tua infrastruttura." Ogni piattaforma che promette "build AI workflows visivamente" e dietro le quinte chiama exec() su input utente sta costruendo lo stesso debito tecnico che Langflow sta pagando con la reputazione.
Il CSIRT Italia ha emesso l'alert AL03/260323/CSIRT-ITA il 23 marzo, classificando la CVE con un CVSS 8.8 (più conservativo del 9.3 del NIST). Le raccomandazioni sono pragmatiche: WAF sull'endpoint vulnerabile, LANGFLOW_AUTO_LOGIN=false, profili AppArmor/SELinux, reverse proxy con OAuth2. La copertura mediatica italiana? Matrice Digitale il 27 marzo e poco altro. L'ecosistema tech italiano ha sostanzialmente ignorato una RCE non autenticata su una piattaforma AI con 15 milioni di download.
Langflow non è una vittima sfortunata. È un progetto che ha visto il proprio codebase esplodere con la CVE-2025-3248, ha scelto di tappare il buco con l'autenticazione invece di eliminare exec() non sandboxato, e ha lasciato lo stesso pattern attivo su un altro endpoint per un anno intero. La langflow vulnerabilità CVE-2026-33017 non è un bug: è la conseguenza prevedibile di una scelta architetturale che privilegia la velocità di sviluppo sulla sicurezza degli utenti. E finché la community AI open-source continuerà a premiare le stelle GitHub invece degli audit di sicurezza, Langflow non sarà l'ultimo progetto a ripetere lo stesso errore due volte.