¡Falla Crítica en Langflow! CVE-2026-33017 RCE Activa

Una falla crítica en Langflow (CVE-2026-33017) permitió a atacantes ejecutar código remoto sin autenticación en menos de 20 horas desde su divulgación pública. El 25 de marzo, CISA agregó la vulnerabilidad a su catálogo de exploits activos confirmados, exigiendo que agencias federales estadounidenses parcheen antes del 8 de abril. La solución inmediata: actualizar a Langflow 1.9.0 o superior, pero antes debés rotar todas tus claves API.

CISA es la agencia de ciberseguridad del gobierno de Estados Unidos, creada bajo el Departamento de Seguridad Nacional. Se encarga de proteger la infraestructura crítica nacional y coordinar la respuesta a incidentes de ciberseguridad.

Qué es Langflow y por qué se convirtió en blanco prioritario

Langflow es un framework open-source que simplifica la construcción de agentes de IA y pipelines RAG con una interfaz visual drag-and-drop. Tenés nodos (bloques) que conectás para encadenar llamadas a modelos de lenguaje: obtener datos de una API, pasar contexto a Claude, guardar el resultado en una base de datos. Todo eso sin escribir código.

Eso la hizo popular rápidamente — 145.000 stars en GitHub, adoptada masivamente en equipos de startups y empresas que construyen aplicaciones con IA. Pero ahí está el problema (spoiler: esto se podía ver venir). Las instancias típicas de Langflow están configuradas con algo muy valioso: claves API de OpenAI, Anthropic, AWS, Google Cloud almacenadas como variables de entorno. Si comprometés una instancia, comprometés el acceso a esos servicios cloud. Y si esos servicios procesan datos sensibles de clientes, la cadena de suministro de software se rompe.

Para los atacantes, Langflow era oro: amplia adopción, acceso a servicios cloud de alto valor, configuración típica que expone secretos. Solo faltaba la vulnerabilidad técnica.

La falla técnica: exec() sin sandbox en un endpoint público

Langflow tiene un endpoint diseñado para que usuarios no autenticados construyan “flujos públicos” — algo así como templates compartidos. El endpoint es POST /api/v1/build_public_tmp/{flow_id}/flow.

El código tiene un parámetro opcional llamado “data”. Si lo suministrás en tu request, el servidor ignora la definición de flujo guardada en la base de datos y usa tu JSON en lugar. Luego ejecuta el código Python de los nodos que vos proporcionaste vía exec() sin sandboxing, validación, ni verificación de seguridad. Una sola request HTTP. Eso es todo.

Pensalo así: es como si WordPress tuviera un endpoint /publicaciones/nueva/ que aceptara código PHP directo en el body de la request y lo ejecutara en el servidor sin autenticación. Te preguntarías si quién diseñó eso estaba consciente.

El advisory publicado el 17 de marzo le dio a los atacantes exactamente esa información: el endpoint, el parámetro vulnerable, y el hecho de que no había autenticación. El CVSS score fue 9.3 de 10 (crítico absoluto). Cubrimos ese tema en detalle en en nuestra guía sobre seguridad en GitHub.

La línea de tiempo: de la divulgación a la explotación en 20 horas

Lo que pasó después fue predecible pero revelador sobre cómo operan los atacantes modernos.

Lo interesante acá es que no existía PoC (prueba de concepto) público. Los atacantes leyeron el advisory, entendieron la vulnerabilidad, escribieron exploits desde cero, y comenzaron a buscar víctimas. Pasó todo en menos de un día.

Qué robaron los atacantes y por qué es grave

Las instancias comprometidas exponían archivos .env (variables de entorno) y .db (bases de datos SQLite). Eso significa: credenciales de OpenAI, Anthropic, claves de AWS, acceso a bases de datos internas, tokens de GitHub Actions, secretos de terceros. En una sola instancia comprometida, un atacante obtiene las llaves de toda tu infraestructura de IA.

El riesgo no es solo “un atacante genera contenido malicioso con tu cuenta de OpenAI y te llega una factura de $50.000”. Es peor. Si tu instancia de Langflow está integrada con un pipeline de CI/CD (que es lo típico), los atacantes pueden inyectar código malicioso en tu flujo de deployment. Ahora tu aplicación en producción ejecuta código que vos no escribiste.

Eso es lo que significa “compromiso de la cadena de suministro de software” — el atacante entra por una vulnerabilidad pública, roba credenciales, y contamina lo que vos distribuís a tus usuarios.

CISA y el catálogo KEV: qué significa para vos

CISA (Cybersecurity and Infrastructure Security Agency) mantiene un catálogo llamado Known Exploited Vulnerabilities (KEV) que lista vulnerabilidades donde hay prueba confirmada de explotación activa en el wild, no especulaciones.

Cuando una vulnerabilidad entra en ese catálogo, las agencias federales estadounidenses tienen un plazo para parchear (en este caso, 8 de abril de 2026) o dejar de usar el producto completamente. Eso es mandato ejecutivo.

Ahora bien, vos no trabajás en una agencia federal (probablemente). Pero el catálogo KEV es un indicador confiable de que esto no es una vulnerabilidad teórica o de bajo riesgo. Es real, está siendo explotada activamente, y si usás Langflow en producción, debería ser tu prioridad máxima.

Cómo proteger tu instancia de Langflow ahora mismo

Paso 1: Actualizar a Langflow 1.9.0 o superior (urgente)

Es la única solución oficial. La versión 1.9.0 parcheó el ejecutable del código sin validación agregando autenticación obligatoria al endpoint vulnerable y validación de inputs. Lo explicamos a fondo en vulnerabilidades en la cadena de npm.

Si usás Docker (que es lo típico):

docker pull langflow/langflow:latest
docker stop langflow-container
docker run -d -p 7860:7860 --name langflow-container langflow/langflow:latest

Si instalaste desde pip, actualiza con pip install --upgrade langflow y reinicia el servicio.

Paso 2: Rotar TODAS tus claves API (inmediatamente después de actualizar)

No esperes a auditar logs. Si tu instancia de Langflow estuvo expuesta a Internet antes del parche, asumir que fue comprometida es lo prudente. Acciones concretas:

• OpenAI: Buscá el dashboard de API keys, eliminá la anterior, generá una nueva, actualizá tu .env
• Anthropic: Misma lógica en console.anthropic.com
• AWS: Si usás credenciales de acceso (lo que no deberías — usá IAM roles), borrá las keys antiguas en IAM console
• Bases de datos: Cambiar contraseñas de acceso a cualquier BD conectada a Langflow

Paso 3: Restringir acceso de red (arquitectura defensiva)

Langflow no debería estar expuesto a Internet sin autenticación. Opciones:

• Reverse proxy con autenticación: Nginx/Apache adelante con OAuth, mTLS, o autenticación básica forzada
• VPN: Solo equipos internos con acceso VPN pueden alcanzar Langflow
• Firewall: Permite tráfico solo desde IPs conocidas de tu organización
• Cloud provider: Si corre en donweb o cualquier VPS, usa security groups para limitar ingress al puerto 7860 solo a redes autorizadas

Paso 4: Auditoría de variables de entorno y secretos

Listá qué secretos tiene Langflow acceso. Comando rápido si corre en Docker:

docker exec langflow-container env | grep -i "api\|key\|secret\|token"

Para cada uno: ¿está siendo usado? ¿Es crítico? ¿Podría exponerse? De ser sí a cualquiera, rotá la credencial.

Paso 5: Monitoreo de conexiones salientes (detección post-compromiso)

Si sospechas que ya fue comprometida, monitorear es clave. Buscá:

• Conexiones TCP salientes a puertos inusuales desde el servidor Langflow
• Procesos Python ejecutándose con payloads de red (netcat, curl, wget)
• Consumo anormal de cuota de APIs (OpenAI, AWS)

Indicadores de compromiso: cómo detectar si ya fuiste atacado

Si Langflow estuvo expuesto antes de actualizar, aquí hay señales concretas a buscar en logs y sistema:

• Requests POST inusuales al endpoint vulnerable en access logs: buscar /api/v1/build_public_tmp/ con métodos POST, especialmente a horas donde no hay actividad típica
• Acceso a archivos .env o .db en horarios raros (analizar logs del OS o contenedor Docker)
• Conexiones de red salientes inesperadas desde el proceso de Langflow hacia IPs no reconocidas
• Cambios en variables de entorno o credenciales de acceso alteradas sin tu acción
• Procesos Python spawn inesperados con parámetros de red

Sysdig desplegó honeypots (instancias falsas de Langflow vulnerable) en múltiples regiones de cloud y documentó el patrón de ataque: escaneo masivo automatizado, luego explotación direc, luego exfiltración. Si ves ese patrón en tus logs, la instancia fue comprometida.

Errores comunes al responder a CVE-2026-33017

Error 1: “Solo actualizar y listo”

Muchos equipos actualizan Langflow y consideran el tema cerrado. Grave error: si estuvo comprometida, los atacantes ya tienen tus claves. Actualizar detiene nuevas explotaciones pero no revoca los secretos que ya robaron. Rotar credenciales es obligatorio, no opcional. Tema relacionado: como sucedió con OpenClaw hace poco.

Error 2: “No tengo Langflow en producción, estoy seguro”

¿Lo usás en dev, staging, o POC? Eso cuenta. Si tiene acceso a credenciales de APIs reales (incluso con límites de cuota), los atacantes pueden usarlas. La línea entre “desarrollo” y “explotable” es muy delgada.

Error 3: Auditar logs sin saber qué buscar

La mayoría de equipos no sabe qué línea de log significa “fuiste atacado”. Buscá específicamente: requests al endpoint /api/v1/build_public_tmp/, parámetro “data” presente, horarios donde nadie debería estar haciendo builds, origen de IP sospechosa (datacenter vs tu rango de IPs conocidas).

Esto me acuerda a lo que pasó con Falla crítica en Langflow explotada a las 20 horas de su div.

Algo parecido pasó en Falla crítica en Langflow explotada a las 20 horas de su div.

Si querés ver un caso reciente, Falla crítica en Langflow explotada a las 20 horas de su div.

Cubrimos esto en detalle en Falla crítica en Langflow explotada a las 20 horas de su div.

Preguntas Frecuentes

¿Cómo sé si mi instancia de Langflow fue comprometida?

Chequeá si en el período entre el 17 de marzo y el día que actualizaste hay requests POST al endpoint /api/v1/build_public_tmp/ en los logs del servidor. Si hay, asumí que fue comprometida. Rota credenciales inmediatamente. Después, analiza qué recursos fueron accedidos usando esas claves robadas (CloudTrail en AWS, audit logs en OpenAI, etc.).

¿Necesito re-crear todas mis bases de datos?

No necesariamente. Dependé del escenario. Si la BD tiene datos sensibles de clientes, y fue comprometida (archivo .db robado), entonces sí: restaurá desde backup anterior al 17 de marzo, o reinicia la BD limpia. Si solo contiene configuración interna, rotar credenciales es suficiente.

¿Qué pasa si me vieron otros atacantes cuando explotaban mi instancia?

Buena pregunta. Una vez que tu instancia fue comprometida la primera vez, las credenciales robadas son públicas en el underground (foros de hacking). Otros atacantes compran ese acceso o lo reutilizan. Esto es por qué rotar es tan crítico — querés invalidar esas credenciales lo antes posible.

¿CISA me persigue si tengo Langflow vulnerable?

Solo si sos una agencia federal estadounidense. Si trabajás en empresa privada en Latinoamérica, CISA no tiene jurisdicción. Pero sí podrían verte involucrado si tu compromiso causó que datos de usuarios estadounidenses fueran expuestos (regulaciones como GDPR aplican a veces). Mejor simplemente actualizar y no robar protagonismo.

Conclusión

CVE-2026-33017 en Langflow fue una falla de arquitectura típica: un endpoint público que debería estar protegido, ejecución de código sin validación, y credenciales críticas almacenadas en plain text. El hecho de que atacantes construyeran exploits funcionales en 20 horas sin PoC público demuestra algo incómodo: el bar para explotación activa de vulnerabilidades críticas es ahora muy bajo.

El parche (Langflow 1.9.0+) cierra la puerta técnica. Pero la respuesta real requiere cuatro acciones en paralelo: actualizar, rotar claves, auditar logs, y restringir acceso de red de ahora en adelante. Si Langflow está en tu stack, esto debería ser P0 en tu sprint actual. No es opcional.

Fuentes

• CISA: New Langflow flaw actively exploited to hijack AI workflows – BleepingComputer
• CVE-2026-33017: How attackers compromised Langflow AI pipelines in 20 hours – Sysdig
• Critical Langflow Flaw (CVE-2026-33017) – The Hacker News
• Known Exploited Vulnerabilities Catalog – CISA
• CISA alerta de explotación activa en Langflow – Hispasec