LiteLLM CVE-2026-42208: una inyección SQL pre-autenticación en la pasarela de IA

¿Qué es CVE-2026-42208?

CVE-2026-42208 (GHSA-r75f-5x8p-qvmc, CVSS 9.3) es una inyección SQL pre-autenticación en LiteLLM, el proxy de código abierto compatible con OpenAI que supera las 22 000 estrellas en GitHub y que sirve de frontal para OpenAI, Anthropic, Bedrock y decenas de proveedores de modelos. El aviso del mantenedor se publicó el 20 de abril de 2026, el parche llegó en v1.83.7 el 19 de abril, y la entrada se replicó en la GitHub Advisory Database global el 24 de abril de 2026. El equipo Sysdig Threat Research observó el primer intento de explotación dirigida 36 horas y siete minutos después, el 26 de abril a las 04:24 UTC. CISA añadió la vulnerabilidad a su catálogo Known Exploited Vulnerabilities el 8 de mayo de 2026.

Cómo funciona

En las versiones afectadas (v1.81.16 hasta v1.83.6), la ruta de verificación de claves API del proxy concatena el valor de la cabecera Authorization: Bearer directamente en un SELECT contra la tabla LiteLLM_VerificationToken, sin enlace de parámetros. La comprobación se ejecuta antes de decidir la autenticación: cualquier cliente que alcance el puerto del proxy puede entonces enviar SQL arbitrario.

La forma observada en producción por Sysdig es directa:

POST /chat/completions HTTP/1.1
Authorization: Bearer sk-litellm' UNION SELECT api_key,NULL,NULL,NULL,NULL FROM "LiteLLM_VerificationToken"--
User-Agent: Python/3.12 aiohttp/3.9.1

El prefijo sk-litellm' no es una clave real — la comilla simple final cierra el literal SQL para que el UNION se ejecute sobre la columna exfiltrada. Dos detalles del operador importan para los defensores. Primero, ya conocía el identificador PascalCase generado por Prisma ("LiteLLM_VerificationToken"), lo que implica la lectura previa del esquema open source de LiteLLM. Segundo, las primeras descargas apuntaron a las tres tablas de mayor valor del proxy: LiteLLM_VerificationToken (claves virtuales y master key), litellm_credentials.credential_values (credenciales en bruto de proveedores aguas arriba) y litellm_config.config_value WHERE param_name='environment_variables' (el entorno de ejecución del proxy, que suele incluir el DSN de PostgreSQL y las URL de webhook).

La corrección cabe en una línea: sustituir la interpolación de cadena por una consulta parametrizada. Aterrizó en v1.83.7 y los mantenedores recomiendan hoy v1.83.10-stable.

Por qué importa

Una inyección SQL contra una aplicación web genérica filtra filas. Una inyección SQL contra una pasarela de IA filtra las claves de cada cuenta de modelo que intermedia. Una sola fila en litellm_credentials contiene de forma habitual una clave de organización OpenAI de producción con un tope mensual de cinco cifras, una clave de consola Anthropic con derechos de workspace-admin y una credencial IAM de AWS Bedrock. Una vez robadas, esas claves pueden reproducirse contra /chat/completions desde cualquier IP — LiteLLM no vincula las claves a una fuente por defecto. El radio de impacto se parece más a un compromiso de cuenta cloud que a un SQLi web clásico.

Tres patrones más amplios merecen atención, coherentes con LMDeploy SSRF (CVE-2026-33626) y con la ola más amplia de CVE de infraestructura IA en 2026:

• Las pasarelas de IA son superficies de credenciales de primer nivel. Agregan secretos de proveedor que antes estaban tras fronteras separadas.
• Las ventanas de explotación se acortan. 36 horas entre el aviso y una explotación con conocimiento de esquema, sin necesidad de un PoC público. Los pipelines defensivos basados solo en CISA KEV no habrían levantado la alerta a tiempo.
• El conocimiento del esquema precede al payload. Los ORM open source publican los nombres de tabla que los atacantes necesitan. El coste del reconocimiento tiende a cero.

Defensas

Pasos concretos, por orden de urgencia:

• Actualice ahora a v1.83.10-stable (o cualquier versión >= v1.83.7). Si el parche está bloqueado, sitúe el proxy detrás de un reverse-proxy que rechace cualquier cabecera Authorization que contenga comillas simples, paréntesis o los tokens UNION, SELECT, FROM, --.
• Trate la base como comprometida para toda instancia accesible desde Internet que haya ejecutado una versión vulnerable. Rote todas las claves virtuales, la master key y cada credencial de proveedor almacenada. Audite los portales de facturación aguas arriba en busca de tráfico /chat/completions desde IPs origen desconocidas.
• Saque el proxy de Internet. Las pasarelas de IA consolidan suficiente valor en credenciales para que la exposición pública ya no sea una postura defendible por defecto — protéjalas con mTLS o un proxy de identidad corporativo.
• Vincule las claves a una fuente. Cuando la plataforma lo permita, limite las claves virtuales a las IP cliente o identidades de servicio esperadas: una clave exfiltrada dejará de ser intercambiable con el llamador legítimo.
• Monitorice la firma de la petición. Una única petición Authorization: Bearer sk-litellm' es un indicador de alta confianza. Los IOC de Sysdig cubren las dos IP origen 65.111.27.132 y 65.111.25.67 (AS200373).
• Inventaríe la superficie pasarela. Los equipos aplicativos despliegan a menudo LiteLLM, OpenLLM y herramientas similares fuera del proceso de seguridad estándar. Encuéntrelos antes que un tercero.

Estado

Elemento	Fecha	Estado
Parche publicado (v1.83.7)	19 abr. 2026	Público
Aviso del mantenedor (GHSA)	20 abr. 2026	Público
Indexación GHSA global	24 abr. 2026	Público
Primer intento de explotación observado	26 abr. 2026	Público (Sysdig)
Entrada del blog de LiteLLM	29 abr. 2026	Público
Incorporación al catálogo CISA KEV	8 may. 2026	Público
Versión recomendada	v1.83.10-stable	Actual

La conclusión es incómoda pero accionable: en mayo de 2026, una pasarela LLM expuesta a Internet con una versión vulnerable debe considerarse comprometida, no simplemente vulnerable.