El 7 de julio de 2026, CISA incorporó CVE-2026-55255 a su catálogo de vulnerabilidades explotadas (KEV) y ordenó a las agencias federales de Estados Unidos corregirla antes del 10 de julio. Lo llamativo no es la urgencia, que es habitual, sino qué se estaba robando con ella: claves de proveedores de LLM, credenciales de nube y secretos de base de datos guardados dentro de los flujos de Langflow.
Langflow es una plataforma de código abierto para construir aplicaciones y agentes de inteligencia artificial encadenando componentes de forma visual. CVE-2026-55255 es una referencia directa a objeto insegura (IDOR): cuando un flujo se localizaba por su identificador, la consulta no comprobaba de quién era, de modo que cualquier usuario autenticado podía ejecutar el flujo de otro con solo indicar su UUID. No es una ejecución remota por sí sola; es un fallo de autorización que abre la puerta a los datos y a los secretos de terceros.
El equipo de investigación de amenazas de Sysdig observó su explotación real desde el 25 de junio. El atacante enumeraba primero los flujos existentes y después reutilizaba esos identificadores para leer los flujos ajenos, con una instrucción tan directa como “leak api keys”. Su objetivo mayor era la ejecución de código, encadenando otro fallo del propio Langflow, y la entrega de un implante de segunda fase.
Este incidente, en el fondo, no va de Langflow. Va de toda una categoría de herramientas de IA que hemos desplegado deprisa, muchas veces expuestas a internet y llenas de credenciales, sin el gobierno que aplicamos al resto de la producción.
Lo esencial
Si tu organización usa Langflow, o cualquier plataforma parecida para orquestar IA, esto es lo que importa hoy:
- Actualiza a la versión 1.9.2 o posterior sin esperar a la próxima ventana de mantenimiento. El fallo se está explotando.
- Sácala de la internet pública. Ninguna instancia de orquestación de IA debería estar abierta: detrás de VPN, con inicio de sesión único y segmentación de red.
- Si estuvo expuesta, rota las claves. Asume que las credenciales incrustadas en tus flujos (LLM, nube, base de datos) están comprometidas y cámbialas ya.
- Caza el patrón en tus registros: enumeración de la interfaz de flujos seguida de accesos a flujos con identificadores distintos desde un mismo origen.
- Trátalas como producción. Langflow, n8n, Flowise o Dify necesitan inventario, gestión de vulnerabilidades y monitorización como cualquier servicio expuesto.
Qué es CVE-2026-55255, en términos conceptuales
Conviene explicarlo a nivel de mecánica, no de receta. Un IDOR aparece cuando una aplicación deja que un usuario acceda a un recurso por su identificador sin comprobar si ese recurso le pertenece. En Langflow, la resolución de un flujo por UUID no incluía esa comprobación de propiedad, así que un usuario autenticado podía invocar el flujo de otro. Los responsables del proyecto lo corrigieron en la rama 1.9.x; la recomendación es actualizar a 1.9.2 o superior.
Su puntuación no es de las más altas, y ese es justo el punto interesante. Se explotó antes que vulnerabilidades con un CVSS mucho mayor porque combinaba dos cosas que buscan los atacantes: era fácil de aprovechar y daba acceso a algo muy valioso. Es la lógica que defendemos al priorizar por explotabilidad real (KEV, EPSS y SSVC) y no solo por la gravedad teórica.
Sysdig lo resume bien: una vulnerabilidad de gravedad media, explotada en la práctica, causa más daño que un CVSS de diez que nadie ataca. El catálogo KEV existe precisamente para ordenar esa realidad.
Por qué un flujo de IA es un botín tan rentable
Los flujos de estas plataformas suelen llevar los secretos escritos dentro de la configuración de sus componentes: claves de OpenAI o Anthropic, credenciales de AWS y contraseñas de bases de datos. Para un atacante son líquidos e inmediatos. Puede revenderlos, o abusar directamente de ellos.
El abuso de una clave de LLM tiene, además, una economía propia: el atacante consume tu cuota y te deja la factura, o usa tu cuenta para tareas que no quiere pagar. Y una credencial de nube o de base de datos rara vez se queda quieta: es el punto de partida para moverse hacia los servicios conectados. Es el problema clásico de las identidades no humanas (NHI): credenciales de máquina con permisos amplios, que casi nadie rota y que apenas se vigilan.
Un patrón que ya habíamos visto en estas plataformas
No es la primera vez. Este mismo año Langflow arrastró CVE-2026-33017, una ejecución remota sin autenticación con CVSS 9,3, que se explotó apenas veinte horas después de hacerse pública. Y la misma plataforma sirvió de entrada al primer ransomware dirigido de principio a fin por una IA que documentamos hace unas semanas.
Los investigadores hablan ya de un patrón sistémico: es la tercera clase de ejecución remota en plataformas de IA del primer trimestre de 2026, y se repite en herramientas como n8n, Flowise, Dify o ComfyUI. El origen es casi siempre el mismo: autenticación desactivada por defecto y decenas de miles de instancias accesibles desde internet.
Por qué los controles de siempre no lo ven
Muchas de estas herramientas se levantaron fuera del gobierno de TI. Un equipo quería prototipar rápido, las puso en una máquina pública para colaborar o enseñar demos, y ahí se quedaron. No tienen dueño para los parches, no figuran en el inventario de activos, no entran en el alcance de la gestión de vulnerabilidades y sus secretos no pasan por un gestor. Es superficie de ataque que la organización no sabe que tiene.
Por eso conviene mirarlo desde dos servicios que atacan justo ese punto ciego: la gestión de la superficie de ataque, para descubrir lo que está expuesto, y un enfoque de gestión continua de la exposición (CTEM), para que ese descubrimiento no sea un ejercicio de una sola vez.
Detección operativa
Sin entrar en cómo se ejecuta el ataque, sí hay señales claras que un defensor puede vigilar. Trátalas como hipótesis de caza y adaṕtalas a tu telemetría:
- En el proxy y en los registros de red, accesos secuenciales a la interfaz de listado de flujos seguidos de lecturas de flujos con identificadores variados desde una misma sesión o dirección IP.
- Sesiones autenticadas que recorren identificadores que no les corresponden: es la huella típica de un IDOR en explotación.
- Salida hacia APIs de LLM (OpenAI, Anthropic) desde equipos que no deberían hablar con ellas, o picos súbitos de consumo y facturación en tus cuentas de LLM o de nube: señal de abuso de claves robadas.
- En el propio servidor de Langflow, procesos hijo inesperados o descarga de artefactos de segunda fase, coherentes con el encadenado hacia ejecución de código.
Si no tienes quien construya y mantenga estas reglas, es exactamente el trabajo de un servicio de búsqueda proactiva de amenazas apoyado en inteligencia de amenazas.
Defensa práctica
Las prioridades, de mayor a menor impacto:
- Actualiza a 1.9.2 o posterior y verifica qué versión tienes desplegada en cada instancia, incluidas las que no recuerdas haber montado.
- Elimina la exposición pública: VPN, inicio de sesión único y segmentación. Estas plataformas no deberían ser accesibles desde internet.
- Deja de incrustar secretos en los flujos. Usa un gestor de secretos y credenciales de vida corta y alcance mínimo, no claves permanentes con permisos amplios.
- Rota lo que haya podido quedar expuesto (claves de LLM, de nube y de base de datos) y revisa su uso reciente en busca de accesos anómalos.
- Ponlas bajo gestión. Incorpora estas herramientas a tu gestión de vulnerabilidades y a la monitorización de un SOC gestionado o un MSSP si no tienes equipo propio para vigilarlas.
- Trata los componentes de IA como terceros. Un modelo, una plataforma o un conector externo entran en tu gestión de riesgo de terceros como cualquier otro proveedor.
Qué significa para NIS2 y DORA
Una instancia de IA expuesta, sin dueño y llena de credenciales es justo lo que NIS2 quiere evitar: la directiva pide gestión de activos, tratamiento de vulnerabilidades y seguridad de la cadena de suministro. No se puede proteger, ni declarar, lo que no se inventaría.
Para las entidades financieras, DORA va un paso más allá: obliga a registrar y gobernar el riesgo TIC de terceros. Una herramienta de IA que concentra claves de nube y de base de datos, y que no figura en ese registro, es un punto ciego de resiliencia operativa que un supervisor no va a pasar por alto.
En resumen
La experimentación con IA de los últimos dos años creó una clase nueva de activos: servicios de cara a internet, llenos de secretos líquidos, desplegados más rápido de lo que el gobierno pudo seguir. CVE-2026-55255 es el recordatorio de que los atacantes ya lo saben. La respuesta no es frenar la IA, sino gobernarla como gobernamos lo demás: inventario, autenticación, secretos gestionados y vigilancia. Lo aburrido, otra vez, es lo que funciona.