Una vulnerabilidad crítica de inyección SQL sin autenticación en LiteLLM ya se ha utilizado en ataques reales pocas horas después de hacerse pública. El fallo puede exponer datos de la base de datos del proxy, incluidas credenciales de proveedores de LLM y secretos operativos. La corrección llega con LiteLLM 1.83.7 y, si hubo exposición, conviene rotar claves y revisar indicadores de compromiso.
El auge de los AI gateways y proxies para centralizar el acceso a modelos ha convertido a piezas como LiteLLM Proxy en un punto único de alto valor: concentran tráfico, aplican políticas y, sobre todo, custodian secretos que abren la puerta a servicios externos. Por eso, cuando aparece un fallo crítico en la capa de autenticación, el impacto no se limita a una aplicación, puede extenderse a los proveedores conectados y a la nube.
El problema identificado como CVE-2026-42208, con severidad crítica (CVSS 9.3), es una inyección SQL que se activa antes de cualquier autenticación. El vector es especialmente delicado porque el atacante no necesita una cuenta ni una clave válida: basta con enviar una cabecera Authorization manipulada a rutas habituales de API de LLM, como POST /chat/completions, para forzar que el servidor construya consultas de base de datos con entrada no confiable. El origen del fallo está en la verificación de claves del proxy, donde el valor aportado por el cliente termina incrustado en el texto de la consulta en lugar de usarse una consulta parametrizada.
En términos prácticos, esto permite leer información de la base de datos del proxy y, dependiendo del contexto, modificarla. El riesgo inmediato es la exposición de tablas con material sensible, como litellm_credentials.credential_values y litellm_config, que pueden incluir configuración de ejecución y variables de entorno. Un detalle especialmente preocupante es que una sola fila en litellm_credentials puede agrupar a la vez claves de OpenAI, Anthropic y credenciales de AWS Bedrock, lo que eleva el impacto potencial desde un incidente en el proxy hasta un compromiso más amplio de cuentas y consumo en cloud.
La rapidez con la que se pasó de la divulgación a los intentos de explotación ha sido llamativa. Se observó actividad en un margen de unas 36 horas desde su publicación e indexación, con el primer intento registrado el 26 de abril de 2026, tras quedar el aviso accesible en la GitHub Advisory Database. Los patrones detectados apuntan a un operador con automatización, con solicitudes identificadas por el User Agent Python/3.12 aiohttp/3.9.1 y una cabecera Authorization que arrancaba con sk-litellm’, usando la comilla simple para cerrar la cadena e inyectar SQL. También se vieron tácticas típicas de enumeración, como cargas UNION y barridos para acertar el número de columnas variando NULL, seguidas de una segunda fase más afinada, ya orientada a nombres de tablas reales y a tokens como LiteLLM_VerificationToken. La actividad se asoció a las IP 65.111.27.132 y 65.111.25.67, con rotación de salida compatible con un mismo actor.
Aunque se detectó sondeo de endpoints de gestión como /key/generate y /key/info sin autenticación, no se confirmó una continuidad clara usando credenciales exfiltradas ni una generación exitosa de nuevas claves virtuales. Aun así, la conclusión operativa es clara: el intervalo entre divulgación y explotación es ya lo bastante corto como para asumir que cualquier instancia expuesta a Internet es objetivo inmediato.
Las versiones afectadas abarcan LiteLLM >= 1.81.16 y < 1.83.7. La corrección está disponible en LiteLLM 1.83.7 stable, publicada el 19 de abril de 2026. Si actualizar no es viable de forma inmediata, se propone como mitigación temporal activar disable_error_logs: true dentro de general_settings, para cortar la ruta por la que la entrada no confiable llega a la consulta vulnerable. Como contención adicional, puede colocarse el proxy detrás de un reverse proxy o WAF que aplique filtrado defensivo de la cabecera Authorization, bloqueando comillas simples y patrones característicos de SQLi como UNION, SELECT, FROM, OR y comentarios tipo —. Esta medida no sustituye al parche, pero puede reducir el riesgo mientras se planifica la actualización.
Dado que el valor real está en los secretos, la respuesta no debería terminar en el despliegue del fix. Es recomendable rotar todas las claves y secretos almacenados o gestionados por LiteLLM, especialmente credenciales de proveedores de LLM y cualquier credencial cloud asociada, además de revisar la exposición y la integridad de la base de datos del proxy. En paralelo, conviene buscar indicadores de explotación en logs HTTP y del perímetro, poniendo el foco en solicitudes a /chat/completions o /v1/chat/completions con Authorization que contenga sk-litellm’ o cadenas UNION SELECT, y tratar cualquier coincidencia como señal de alta confianza. También resulta prudente monitorizar consumo y facturación en OpenAI, Anthropic y AWS Bedrock para detectar uso anómalo a partir del 24 de abril de 2026, y correlacionarlo con IPs y claves virtuales.
Más allá de este CVE, se han mencionado otras debilidades en LiteLLM Proxy que podrían encadenarse, como una SSTI en /prompts/test y ejecución de comandos vinculada a endpoints de prueba de MCP, lo que refuerza la necesidad de revisar qué rutas están expuestas y aplicar endurecimiento de forma conjunta. Una práctica útil para equipos defensivos es inventariar instancias potencialmente publicadas buscando servicios HTTP cuyo título empiece por LiteLLM, y después verificar configuración, parches y exposición. Este contexto cobra más relevancia al recordarse un incidente reciente de cadena de suministro en PyPI relacionado con el proyecto, un recordatorio de que la higiene de dependencias y la rotación de credenciales no es opcional en entornos que manejan secretos.
En resumen, CVE-2026-42208 es un ejemplo de cómo un fallo en la verificación de claves en un proxy de LLM puede convertirse en un incidente de seguridad con impacto transversal. Parchear a 1.83.7, reducir superficie de exposición moviendo LiteLLM a red interna y publicándolo solo mediante un frontal con controles estrictos, revisar trazas de ataque y rotar secretos son pasos clave para limitar daños y evitar que un ataque al gateway termine comprometiendo proveedores y cuentas cloud.
Más información
- The Hacker News – LiteLLM CVE-2026-42208 SQL Injection Exploited within 36 Hours of Disclosure : https://thehackernews.com/2026/04/litellm-cve-2026-42208-sql-injection.html
- Sysdig – CVE-2026-42208: Targeted SQL injection against LiteLLM’s authentication path discovered 36 hours following vulnerability disclosure : https://www.sysdig.com/blog/cve-2026-42208-targeted-sql-injection-against-litellms-authentication-path-discovered-36-hours-following-vulnerability-disclosure
- GitHub Security Advisory (BerriAI LiteLLM) – LiteLLM has SQL Injection in Proxy API key verification (GHSA-r75f-5x8p-qvmc) : https://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc
- runZero – LiteLLM Proxy vulnerabilities: How to find impacted assets : https://www.runzero.com/blog/litellm/
- BleepingComputer – Hackers are exploiting a critical LiteLLM pre-auth SQLi flaw : https://www.bleepingcomputer.com/news/security/hackers-are-exploiting-a-critical-litellm-pre-auth-sqli-flaw/
Deja una respuesta