El almacenamiento centralizado de credenciales es lo que hace que esta vulnerabilidad tenga un impacto especialmente alto. Una instancia de LiteLLM comprometida no solo expone una clave API -- potencialmente expone todas las credenciales en la nube que la organización ha configurado en todos los proveedores de LLM.

Detalles de la Vulnerabilidad

Causa Raíz

El fallo existe en el proceso de verificación de claves API del proxy de LiteLLM. Cuando llega una solicitud, el proxy comprueba el valor del encabezado Authorization: Bearer contra su base de datos para autenticar al llamante. En las versiones afectadas, el valor del token bearer se concatenaba directamente en la cadena de consulta SQL en lugar de pasarse como entrada parametrizada:

Una comilla simple en el valor bearer permite a un atacante escapar del literal de cadena y añadir sentencias SQL arbitrarias. Debido a que el punto de inyección está en la propia comprobación de autenticación, no se necesitan credenciales válidas para desencadenarla.

Vía de Ataque

1. El atacante envía una solicitud HTTP manipulada a cualquier endpoint de API de LLM (por ejemplo, POST /chat/completions)
2. El encabezado Authorization: Bearer contiene una carga útil de inyección SQL
3. La solicitud fluye a través de la ruta de manejo de errores del proxy y llega a la consulta vulnerable
4. El atacante puede ejecutar sentencias SELECT arbitrarias o potencialmente INSERT/UPDATE/DELETE contra el backend PostgreSQL
5. Las tablas de la base de datos que contienen claves API, credenciales de proveedores y datos de configuración quedan expuestas

Qué Atacaron los Atacantes

El Equipo de Investigación de Amenazas de Sysdig observó intentos de explotación en entornos reales dirigidos a:

• Tabla LiteLLM_VerificationToken -- claves API virtuales y controles de acceso
• Tablas de almacenamiento de credenciales -- claves API de proveedores de LLM upstream (OpenAI, Anthropic, etc.)
• Tablas de configuración -- definiciones de modelos, presupuestos de gasto, ajustes de limitación de velocidad

Cronología de Explotación

La ventana de explotación de 36 horas es consistente con un actor de amenazas organizado que utiliza escaneo automatizado para monitorear nuevas publicaciones de CVE y desarrollar o adaptar rápidamente código de explotación. La inyección SQL es una clase de vulnerabilidad bien comprendida -- una vez identificada la ruta de código afectada, la armamentización es sencilla.

Evaluación de Impacto

Confidencialidad: Alta -- el contenido de la base de datos es legible, incluidas las credenciales
Integridad: Alta -- la base de datos es escribible, las claves pueden añadirse, modificarse o eliminarse
Disponibilidad: Media -- el proxy puede interrumpirse mediante la modificación de la base de datos
Autenticación requerida: Ninguna -- completamente pre-autenticación
Acceso de red requerido: Sí -- el atacante debe poder alcanzar el puerto del proxy

Por qué esto importa más allá de un SQLi típico: LiteLLM está específicamente diseñado para centralizar la gestión de credenciales. Una organización que ejecuta una instancia comprometida de LiteLLM puede haberla configurado con claves API para OpenAI, Anthropic, Azure OpenAI, AWS Bedrock y otros proveedores. Cada una de esas claves representa acceso a servicios de LLM de pago con límites de gasto potencialmente significativos. Más allá del abuso de gasto en LLM, las credenciales de proveedores de nube en la base de datos podrían permitir movimiento lateral hacia entornos AWS, Azure o GCP.

Versiones Afectadas

Oportunidades de Detección

Nivel de Red/WAF

Busque solicitudes HTTP a endpoints de LiteLLM que contengan metacaracteres SQL en el encabezado Authorization:

Indicadores a buscar en los registros del proxy:

• Solicitudes a /chat/completions, /embeddings u otras rutas API con tokens bearer malformados
• Valores bearer que contengan comillas simples, dobles guiones, UNION, SELECT u otras palabras clave SQL
• Alto volumen de respuestas 4xx del proxy con encabezados Authorization variados desde la misma IP de origen

Nivel de Base de Datos

• Consultas SELECT inesperadas contra LiteLLM_VerificationToken con cláusulas WHERE inusuales
• Acceso a tablas de credenciales o configuración fuera de los patrones normales de consulta de la aplicación
• Registros de claves API nuevos o modificados no creados a través de la interfaz de administración

MITRE ATT&CK

Acciones Recomendadas

Inmediatas (si ejecuta versiones afectadas):

1. Actualice a LiteLLM >= 1.83.7-stable inmediatamente
2. Si estuvo expuesto a Internet durante la ventana vulnerable (19 de abril - despliegue del parche), trátelo como un posible compromiso -- no asuma que sin parche = sin compromiso
3. Rote todas las claves API y credenciales en la nube almacenadas en la base de datos de LiteLLM
4. Revise los registros de acceso del proxy en busca de indicadores de inyección SQL en los encabezados Authorization

A corto plazo: 5. Restrinja el acceso de red al puerto del proxy de LiteLLM -- no debería estar directamente expuesto a Internet sin autenticación delante 6. Active el registro de consultas de la base de datos para detectar futuros intentos de inyección 7. Añada reglas WAF para inspeccionar los encabezados Authorization en busca de metacaracteres SQL

Continuas: 8. Suscríbase a las alertas KEV de CISA -- esta vulnerabilidad estaba siendo explotada activamente antes de que la mayoría de los ciclos de parcheo pudieran detectarla 9. Trate la infraestructura de IA como almacenes de credenciales de alto valor -- los mismos controles de seguridad aplicados a los gestores de secretos deberían aplicarse a los despliegues de proxies de LLM

Notas del Analista

Por qué la infraestructura de IA es un objetivo creciente: LiteLLM y herramientas similares ocupan una posición privilegiada -- contienen credenciales de servicios en la nube de pago con altos límites de gasto y a menudo son desplegadas por equipos de ingeniería en lugar de equipos de seguridad, con una revisión de seguridad menos madura. El equipo de Sysdig señaló específicamente que los operadores de LiteLLM "confían en él para centralizar credenciales de nivel cloud", convirtiéndolo en un objetivo atractivo para el robo de credenciales y el abuso de servicios de LLM (usar claves API robadas para ejecutar sus propias consultas contra modelos de pago).

La ventana de explotación de 36 horas es un punto de referencia: Esto no es una anomalía. Los actores de amenazas monitorean activamente los feeds de publicación de CVE y las bases de datos de avisos. Para vulnerabilidades críticas pre-autenticación en software de código abierto ampliamente utilizado, asuma que la explotación comienza dentro de 24-48 horas tras la divulgación pública. Los SLA de parcheo deben tener en cuenta esta realidad -- una ventana de parcheo de 30 días no es apropiada para vulnerabilidades pre-autenticación con CVSS 9+.

El KEV de CISA como señal de priorización: El catálogo KEV solo incluye vulnerabilidades con explotación confirmada en entornos reales. Si un CVE aparece en KEV, no es teórico -- alguien ya lo ha utilizado contra objetivos reales. Las organizaciones deberían tratar las adiciones a KEV como elementos de acción inmediata independientemente de sus umbrales internos de priorización basados en CVSS.

Referencias

• CISA KEV -- CVE-2026-42208
• Análisis de Sysdig TRT
• Cobertura de The Hacker News
• Security Affairs
• GHSA-r75f-5x8p-qvmc
• MITRE ATT&CK T1190
• MITRE ATT&CK T1555