Resumen
Se ha identificado una vulnerabilidad de tipo Insecure Direct Object Reference (IDOR) en el endpoint /api/v1/responses de Langflow. Un atacante autenticado puede ejecutar cualquier flujo perteneciente a otro usuario simplemente especificando el flow ID de la víctima en la solicitud, sin necesidad de privilegios adicionales.
Detalles técnicos
La vulnerabilidad reside en la función auxiliar get_flow_by_id_or_endpoint_name, ubicada en src/backend/base/langflow/helpers/flow.py (líneas 399-414). Cuando se accede a un flujo mediante su UUID, la función consulta la base de datos directamente sin verificar si el usuario autenticado es el propietario de dicho flujo.
El comportamiento defectuoso se puede observar en el siguiente fragmento:
async def get_flow_by_id_or_endpoint_name(flow_id_or_name: str, user_id: str | UUID | None = None) -> FlowRead:
async with session_scope() as session:
try:
flow_id = UUID(flow_id_or_name)
# Al usar UUID, la consulta se realiza SIN verificar user_id
flow = await session.get(Flow, flow_id) # Sin comprobación de user_id
except ValueError:
endpoint_name = flow_id_or_name
stmt = select(Flow).where(Flow.endpoint_name == endpoint_name)
# Solo al usar endpoint_name se verifica el user_id
if user_id:
stmt = stmt.where(Flow.user_id == uuid_user_id)
Esta función es utilizada por el endpoint /api/v1/responses, definido en src/backend/base/langflow/api/v1/openai_responses.py (línea 589). La inconsistencia en la lógica de autorización entre la búsqueda por UUID y la búsqueda por nombre de endpoint es el origen de la vulnerabilidad.
Prueba de concepto
El siguiente comando demuestra cómo un atacante (usuario A) puede ejecutar el flujo de una víctima (usuario B) conociendo únicamente su flow ID:
curl -X POST "http://localhost:7860/api/v1/responses" \
-H "x-api-key: sk-ATTACKER_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "VICTIM_FLOW_ID",
"input_value": "test",
"stream": false
}'
# Devuelve 200 y ejecuta el flujo de la víctima
Impacto
Cualquier usuario autenticado en el sistema puede:
- Ejecutar cualquier flujo del sistema conociendo su flow ID.
- Acceder a datos potencialmente sensibles procesados por los flujos de la víctima.
- Consumir los recursos computacionales y de cuota de otros usuarios.
El impacto es significativo en entornos multiusuario donde los flujos pueden contener lógica de negocio confidencial, credenciales embebidas o procesar información sensible.
Corrección aplicada
La vulnerabilidad fue corregida en el PR #12832 (fix(security): close IDOR in get_flow_by_id_or_endpoint_name), fusionado el 22 de abril de 2026 y publicado en Langflow 1.9.1.
La corrección normaliza el user_id una sola vez y aplica la verificación de propiedad en ambas ramas de búsqueda, tanto por UUID como por endpoint_name:
flow_id = UUID(flow_id_or_name)
flow = await session.get(Flow, flow_id)
if flow is not None and uuid_user_id is not None and flow.user_id != uuid_user_id:
flow = None # La búsqueda entre usuarios cae al 404 compartido
Puntos clave de la corrección:
- Las búsquedas entre usuarios devuelven 404 (no 403), evitando así un oráculo de existencia de flujos basado en la diferencia entre respuestas 403 y 404.
- Los endpoints
/api/v1/responsesy/api/v2/workflowpasanuser_idde forma explícita, por lo que corregir la función auxiliar los cierra directamente. Las rutas/api/v1/run*fueron adicionalmente migradas desde una dependencia directa deget_flow_by_id_or_endpoint_namea dependencias con conciencia de autenticación, como medida de defensa en profundidad. - Un
user_idmalformado ahora falla de forma segura devolviendo 404 en lugar de un error 500 sin tratar. - Las rutas de webhook mantienen intencionalmente la búsqueda sin restricción de usuario, ya que son públicas por diseño y disponen de una verificación de propiedad explícita en otro punto.
- Se han añadido pruebas de regresión que cubren el caso de UUID entre usuarios y reproducen el PoC original contra
/api/v1/responses.
Recomendación
Se recomienda actualizar a Langflow 1.9.1 o superior a la mayor brevedad posible, especialmente en despliegues multiusuario o expuestos a redes no confiables.
Reconocimientos
La vulnerabilidad fue divulgada de forma responsable por los investigadores de seguridad: @yzeirnials, @johnatzeropath, @LeftenantZero y @Zwique.
