El endpoint de build público de Langflow: RCE sin autenticar, armado en 20 horas

¿Qué es esto?

Langflow es un framework de código abierto ampliamente desplegado, con interfaz visual, para construir agentes LLM y pipelines RAG (Retrieval-Augmented Generation). CVE-2026-33017, divulgada el 17 de marzo de 2026, es una falla de ejecución remota de código sin autenticación en su endpoint de build público. NVD la puntúa con 9,8 (CVSS 3.1); la ficha CNA de GitHub la valora en 9,3 (CVSS 4.0). Es raro que alguno de esos valores sea el titular. Aquí el titular es el cronómetro: el equipo de investigación de amenazas de Sysdig observó explotación in the wild dentro de las 20 horas posteriores al aviso, antes de que existiera ninguna prueba de concepto pública. Los atacantes leyeron el aviso, escribieron el exploit y empezaron a escanear internet.

Este artículo es un análisis defensivo de una vulnerabilidad ya divulgada y ya corregida. No se reproduce ningún payload: el parche es público, la lección es operativa.

Cómo funciona

La falla reside en un único endpoint accesible sin autenticación:

POST /api/v1/build_public_tmp/{flow_id}/flow

En las versiones hasta la 1.8.1, este endpoint acepta un parámetro opcional data. Cuando se suministra, el endpoint construye el flow a partir de datos de flow controlados por el atacante en lugar de la definición almacenada en la base de datos. Un «flow» de Langflow es un grafo de nodos, y las definiciones de nodo pueden llevar código Python. Esa ruta de código llega a exec() sin ningún sandbox, de modo que el código de nodo aportado por el atacante se ejecuta en el host con los privilegios del proceso Langflow.

Petición (sin autenticar)
  -> endpoint build_public_tmp
  -> `data` opcional = grafo de flow del atacante
  -> la definición de nodo contiene Python
  -> exec()  [sin sandbox]
  -> el código se ejecuta en el host

El parche en la 1.9.0 elimina por completo el parámetro data del endpoint de build público, de forma que ya no se le puede entregar un grafo controlado por el atacante. Hay un matiz importante: una versión intermedia 1.8.2 se presentó como corregida, pero JFrog Security Research demostró que la 1.8.2 seguía siendo explotable y no pudo identificar un parche correspondiente en sus commits. En la práctica, el número de versión por sí solo no era una señal fiable de remediación.

En la fase de pos-explotación, distintos investigadores reportaron intrusiones que pivotaban directamente hacia el valor: robo de credenciales en la nube (claves AWS) y despliegue de cargas tipo worker en los hosts comprometidos. El endpoint otorga ejecución de código sin autenticación; todo lo que viene después es pos-explotación corriente, según lo que el host de Langflow pueda alcanzar.

Por qué importa

La primera razón es la ventana de armado de 20 horas. No había ningún PoC que copiar. El texto del aviso bastó para reconstruir el bug, y la distancia entre «divulgación» y «escaneo a escala de internet» cayó por debajo de un día. Cualquier SLA de parcheo que asuma una semana de calma tras la publicación de una CVE está calibrado sobre un modelo de amenaza que ya no se sostiene para las herramientas de IA expuestas a internet.

La segunda razón es dónde se ejecuta este software. Langflow es una herramienta de construcción: una comodidad para desarrolladores que con frecuencia acaba expuesta en una VM en la nube con amplio acceso saliente y credenciales de nube ambientales, precisamente porque «solo» era una herramienta de prototipado interno. Es el peor host posible para una RCE sin autenticación. La CISA añadió CVE-2026-33017 a su catálogo Known Exploited Vulnerabilities el 25 de marzo de 2026, con un plazo de remediación al 8 de abril para las agencias federales civiles bajo la directiva BOD 22-01, señal de que estaba afectando a despliegues expuestos reales, no solo a instancias de laboratorio.

La tercera razón: exec() sobre datos de grafo controlados por el usuario es un patrón, no un caso aislado. Muchos frameworks de orquestación de LLM y de construcción de agentes evalúan «flows», «herramientas» o «skills» aportados por el usuario que incrustan código. Si tu propio stack convierte una definición de agente serializada en Python o shell ejecutado, puede que tengas el mismo bug con otro nombre. El grafo de nodos de Langflow es solo su instancia más visible.

Defensas

1. Actualiza a la 1.9.0 o posterior, y verifica; no confíes en el número de versión. Dado el bypass de la 1.8.2, confirma que el parámetro data ha desaparecido de build_public_tmp en tu build en producción, en vez de suponer que una release etiquetada como «corregida» lo está realmente.

2. Saca Langflow de la internet pública. Un constructor de flows no tiene por qué escuchar en 0.0.0.0 con una IP enrutable. Vincúlalo a localhost, o colócalo detrás de una VPN / proxy inverso autenticado con una ACL de red. La mayoría de las instancias explotadas simplemente eran accesibles.

3. Recalibra los SLA de parcheo para las herramientas de IA expuestas a internet. La cifra de las 20 horas es ahora tu número de planificación. Trata la publicación del aviso —no la del PoC— como el inicio del cronómetro de explotación, con una vía de urgencia fuera de ciclo para las RCE sin autenticación en activos expuestos.

4. Elimina las credenciales ambientales y restringe el egress. Ninguna clave AWS/nube permanente en el host de Langflow; usa accesos IAM acotados y efímeros y salida denegada por defecto. Esto mitiga el robo de credenciales y el despliegue de workers observados en pos-explotación, aunque la ejecución se produzca.

5. Elimina exec()/eval() sobre definiciones controladas por el usuario en tus propios constructores. Si las definiciones de agente/flow/skill pueden llevar código, ejecútalas en un sandbox (proceso separado, seccomp, contenedor sin montajes del host ni red), nunca en línea dentro del proceso del orquestador.

6. Caza los indicadores. Alerta sobre las peticiones a build_public_tmp, sobre procesos hijos anómalos generados por el proceso Langflow y sobre conexiones salientes inesperadas (endpoints de credenciales, brokers C2/worker desconocidos). Inventaría tu exposición con un escaneo externo (Shodan/Censys) antes de que lo haga un atacante.

Estado

Elemento	Referencia	Fecha	Notas
Divulgación CVE-2026-33017	NVD / CNA GitHub	2026-03-17	RCE sin autenticar, CVSS 3.1 9,8 / CVSS 4.0 9,3
Explotación in the wild	Sysdig TRT	~2026-03-18	Dentro de las 20 horas del aviso, sin PoC público
Añadida a CISA KEV	CISA / Help Net Security	2026-03-25	Plazo de remediación FCEB 2026-04-08 (BOD 22-01)
Parche	Langflow 1.9.0	2026	Elimina el parámetro data de build_public_tmp
1.8.2 aún explotable	JFrog Security Research	2026	Release intermedia «corregida» demostrada eludible

El bug está corregido. La lección reutilizable no va de Langflow en absoluto: un constructor sin autenticación que ejecuta código aportado por el usuario, dejado expuesto a internet, será explotado a partir del texto del aviso más rápido de lo que la mayoría de los equipos pueden programar una ventana de parcheo. Encuentra tus herramientas de IA expuestas y ciérralas antes de que el próximo aviso ponga esa suposición a prueba por ti.