Langflow vulnerabilità CVE-2026-33017: exec() senza sandbox, la stessa falla due volte
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.
Un POST, una exec(), game over
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.
