Secuestro de flujos entre inquilinos en Langflow por un control de autorización defectuoso

What is this?

Langflow es un framework visual de código abierto muy extendido para construir agentes LLM y pipelines de generación aumentada por recuperación (RAG). El 19 de junio de 2026, sus mantenedores publicaron un aviso de seguridad sobre una referencia directa a objetos insegura (IDOR) en el endpoint /api/v1/responses: cualquier usuario autenticado podía ejecutar un flujo perteneciente a otro usuario con solo indicar el identificador de ese flujo en la petición. El endpoint aceptaba un identificador de flujo suministrado por el cliente, pero nunca comprobaba que quien llamaba fuera realmente su propietario.

El fallo importa porque los flujos de Langflow suelen incrustar secretos activos — claves de proveedores LLM, credenciales de nube, cadenas de conexión a bases de datos — directamente en la configuración de sus componentes. Secuestrar el flujo ajeno no es, por tanto, solo una ejecución no autorizada: es una vía hacia sus credenciales. El equipo de Threat Research de Sysdig reportó la primera explotación observada en entornos reales el 25 de junio de 2026, y la CISA estadounidense añadió la vulnerabilidad a su catálogo Known Exploited Vulnerabilities el 7 de julio de 2026, con un plazo de mitigación hasta el 10 de julio para las agencias civiles federales. La corrección se había publicado antes, en Langflow 1.9.1.

How it works

La causa raíz es una única comprobación de propiedad ausente en la función auxiliar get_flow_by_id_or_endpoint_name (helpers/flow.py). Cuando un flujo se busca por endpoint_name legible, la consulta se limita al usuario actual. Cuando el mismo flujo se busca por UUID, no lo hace:

# Ilustrativo — la rama vulnerable resolvía un flujo por UUID
# sin confirmar que el solicitante fuera su propietario.
flow_id = UUID(flow_id_or_name)
flow = await session.get(Flow, flow_id)   # sin comprobación de propietario aquí
# ...
# La rama endpoint_name, en cambio, sí filtraba por user_id.

El endpoint /api/v1/responses es compatible con OpenAI-Responses: trata el campo model como un UUID de flujo. Entréguele el UUID de otro inquilino y la plataforma ejecuta el flujo de ese inquilino — bajo las credenciales incrustadas de ese inquilino — a través de su propia ruta de ejecución legítima.

Existe una restricción honesta, y conviene decirla con claridad: un UUID de flujo de Langflow es un valor aleatorio de 122 bits. No puede obtenerse por fuerza bruta, y la ruta endpoint_name está correctamente acotada, de modo que no hay atajo por adivinación de slug. La explotación depende de obtener primero un identificador de flujo válido. En la intrusión observada, el operador extrajo el listado GET /api/v1/flows/ — que divulgaba los identificadores — y luego reprodujo esos identificadores contra el endpoint responses. Es el encadenamiento clásico divulgación hacia IDOR: un endpoint de listado demasiado permisivo es lo que convierte una referencia de objeto «inadivinable» en un ataque operativo.

Ejemplo de prompt

El fragmento siguiente ilustra la técnica de forma defensiva: el endpoint de responses trataba el campo model como un UUID de flujo y lo ejecutaba sin comprobar la propiedad, de modo que un ID de flujo filtrado podía ejecutar el flujo de otro tenant bajo sus credenciales embebidas. No se muestra ningún exploit funcional — esto es para defensores.

# Langflow cross-tenant flow hijack (illustrative, defensive)
# The /api/v1/responses endpoint treats "model" as a flow UUID and
# ran it WITHOUT checking the caller owned it (pre-1.9.1):
victim_flow_id = "[REDACTED-flow-uuid]"   # first leaked via GET /api/v1/flows/
POST /api/v1/responses  { "model": victim_flow_id, "input": "[hidden instruction]" }
# -> runs another tenant's flow under THEIR embedded API keys.
# Root cause: missing ownership check on the UUID lookup path (IDOR).
# Defense: upgrade to Langflow 1.9.1+, scope object lookups to the caller,
# authorize/rate-limit ID-listing endpoints, and vault your secrets.

Why it matters

La lección de este caso es que la puntuación CVSS no es un ranking de explotabilidad. El fallo de autorización de flujos obtiene un 9.9 porque rompe el alcance entre inquilinos, pero Sysdig vio al mismo operador tratarlo como una ocurrencia de última hora de dos peticiones, mientras concentraba su esfuerzo en un fallo distinto y no autenticado de ejecución remota de código en el mismo producto (puntuado más bajo, en 9.3, pero lanzable de forma masiva por Internet y sin credenciales). En una única instancia autoalojada, la ejecución de código es un superconjunto estricto de lo que aporta el IDOR: por eso los atacantes que optimizan el esfuerzo frente al beneficio recurren al RCE.

El IDOR gana su gravedad en un escenario concreto: Langflow multiinquilino o gestionado. Allí, los flujos de los inquilinos se ejecutan en workers aislados, de modo que el RCE queda contenido por inquilino y no puede, por sí solo, cruzar la frontera. El fallo de autorización sí puede — de forma sigilosa, en la capa de aplicación, como una llamada de API de apariencia legítima cuya única anomalía es el identificador de flujo equivocado. Para quien opere Langflow como servicio compartido, esta es la ruta que alcanza los secretos de otro cliente, y queda muy por debajo de la huella de detección del ruidoso RCE.

La lección más amplia trasciende este único producto. Las plataformas de orquestación de IA concentran credenciales por diseño, lo que las convierte en objetivos de alto valor, y sus bases de código de rápida evolución siguen introduciendo errores clásicos de autorización web. Trate estas plataformas con el mismo rigor de control de acceso que aplicaría a cualquier SaaS multiinquilino.

Defenses

1. Parchee y confirme la versión. La corrección llegó en Langflow 1.9.1 (PR #12832); use la última versión. Ahora la propiedad se verifica en ambas ramas de búsqueda, y las búsquedas entre usuarios devuelven un 404 en lugar de un 403 para evitar un oráculo de existencia.
2. Trate los endpoints de divulgación de identificadores como parte de la superficie de ataque del IDOR. La ruta de listado que filtraba los UUID de flujo es lo que hacía la falla alcanzable. Los endpoints de enumeración de objetos merecen la misma revisión de autorización y limitación de tasa que las acciones sensibles que desbloquean.
3. Deje de incrustar secretos en claro en los flujos. Referencie las credenciales mediante un gestor de secretos o un almacén de variables de la plataforma, en lugar de pegar claves de proveedores y de nube en la configuración de los componentes. Si un flujo quedó expuesto, rote cada clave que portaba — asuma la captura.
4. No exponga instancias autoalojadas sin autenticación. El operador observado sondeaba primero el valor por defecto auto_login sin autenticación. Coloque Langflow tras autenticación y controles de red; nunca publique una instancia con capacidades de administración en la Internet abierta.
5. Imponga aislamiento en la capa de aplicación para despliegues multiinquilino. El sandboxing por worker y por inquilino no detiene una ruptura de autorización de aplicación. Acote cada búsqueda de objeto al solicitante y pruebe explícitamente el caso entre inquilinos.
6. Vigile la cadena, no solo el payload. Una llamada de enumeración (/api/v1/flows/) seguida de inmediato por llamadas /api/v1/responses que portan identificadores recién listados es una señal potente. Sysdig y SentinelOne han publicado indicadores de compromiso para la campaña observada.

Status

Elemento	Referencia	Fecha	Notas
Aviso del proveedor (IDOR, CWE-639)	GHSA-qrpv-q767-xqq2 / CVE-2026-55255	2026-06-19	CVSS 9.9, alcance cambiado; afecta a < 1.9.1
Corrección publicada	Langflow 1.9.1 (PR #12832)	2026-04-22 (merge)	Propiedad verificada en ambas rutas
Primera explotación en entornos reales	Sysdig TRT	2026-06-25	Cadena enumeración → responses; prompt «leak api keys»
Añadido al CISA KEV	Alerta CISA	2026-07-07	Plazo federal de mitigación 2026-07-10
RCE encadenado (mismo producto)	CVE-2026-33017	KEV 2026-03-25	No autenticado, CVSS 9.3, explotado en masa en ~20 h

Se respetó la divulgación responsable: los reportantes fueron acreditados y se publicó una corrección antes del aviso público. La conclusión correcta no es «otro CVE de IA», sino un recordatorio: los errores clásicos de autorización defectuosa aterrizan ya en las herramientas que custodian sus claves de modelo y de nube — y que una puntuación CVSS alta informa del impacto, no de qué falla alcanzará primero un atacante.