La vulnerabilidad crítica CVE‑2026‑42208, detectada en el popular AI gateway LiteLLM (desarrollado por BerriAI), está siendo explotada activamente para robar datos sensibles y claves de acceso a proveedores de grandes modelos de lenguaje (LLM). Menos de dos días después de publicarse los detalles técnicos, se han observado ataques reales dirigidos a instancias expuestas de LiteLLM.
Descripción técnica de CVE‑2026‑42208 en LiteLLM
La falla CVE‑2026‑42208 presenta una puntuación base CVSS 9.3 y se clasifica como SQL injection. El origen del problema reside en el mecanismo de validación de claves API del proxy: el valor proporcionado por el cliente se incrustaba directamente en una consulta SQL en lugar de emplear parámetros preparados o escape seguro, contraviniendo las buenas prácticas recogidas por OWASP.
Según el aviso de seguridad GHSA‑r75f‑5x8p‑qvmc, un atacante no autenticado puede enviar un encabezado Authorization manipulado a cualquier ruta de LLM (por ejemplo, POST /chat/completions). A través de un flujo específico de gestión de errores, ese valor termina en una consulta SQL vulnerable, lo que abre la puerta tanto a la lectura como a la posible modificación de registros en la base de datos de LiteLLM.
La vulnerabilidad afecta a versiones anteriores a LiteLLM 1.83.7‑stable, donde el equipo de desarrollo corrigió el fallo el 19 de abril de 2026. Se recomienda contrastar la versión desplegada con la información actualizada en el repositorio oficial de GitHub para confirmar el estado de exposición.
Cómo se explota la SQL injection en LiteLLM en la práctica
La SQL injection sigue apareciendo en los principales informes de amenazas como una de las técnicas más frecuentes contra aplicaciones web y APIs. En el caso de LiteLLM, el punto crítico se encuentra en el sistema de registro y gestión de errores, donde el valor del API key, sin depuración previa, se integra en una sentencia SQL.
Controlando el contenido del encabezado Authorization, un atacante puede alterar la estructura de la consulta, forzando a la base de datos a devolver columnas adicionales, datos de otras tablas o incluso ejecutar operaciones de escritura. Esta explotación se produce antes de completar cualquier proceso de autenticación, lo que la convierte en especialmente peligrosa para instancias expuestas en Internet sin controles adicionales de acceso.
Línea temporal y comportamiento del atacante
Investigaciones de Sysdig sitúan la primera tentativa de explotación el 26 de abril de 2026 a las 16:17 UTC, aproximadamente 26 horas después de que el aviso de GitHub se indexara en la GitHub Advisory Database y dentro de una ventana de 36 horas desde la divulgación pública. Este margen ilustra la rapidez con la que los actores maliciosos operacionalizan vulnerabilidades críticas en software ampliamente adoptado.
La actividad inicial se originó desde la dirección IP 65.111.27[.]132, con una serie de peticiones diseñadas para explotar la SQL injection. Tras unos 20 minutos, el origen cambió a 65.111.25[.]67, manteniendo el mismo patrón de pruebas y añadiendo consultas no autenticadas a endpoints de gestión de credenciales.
Los objetivos principales fueron las tablas litellm_credentials.credential_values y litellm_config, que almacenan claves de proveedores LLM y parámetros de configuración del runtime. No se observaron accesos a litellm_users ni litellm_team, lo que sugiere que el operador conocía la estructura de la base de datos y perseguía específicamente la exfiltración de secretos, no el compromiso de cuentas de usuario.
Impacto de la filtración de la base de datos de LiteLLM
LiteLLM es un AI gateway de código abierto con más de 45.000 estrellas y 7.600 forks en GitHub, usado para unificar y abstraer el acceso a múltiples proveedores de LLM. En una sola fila de la tabla litellm_credentials pueden coexistir claves de varios servicios cloud de alto valor.
De acuerdo con el análisis de Sysdig, una entrada típica podría incluir un API key organizacional de OpenAI con límites de gasto elevados, un token de consola de Anthropic con permisos administrativos y credenciales IAM de AWS Bedrock. La exposición completa de esta información se asemeja más a la comprometida total de una cuenta cloud que a un incidente clásico de SQL injection en una aplicación web aislada.
Este escenario se agrava por el hecho de que, apenas un mes antes, el proyecto LiteLLM fue objetivo de un ataque a la cadena de suministro (supply chain attack) atribuido al grupo TeamPCP, centrado también en el robo de secretos de usuarios downstream. La sucesión de incidentes confirma que las plataformas de orquestación de IA se han convertido en un vector prioritario para la ciberdelincuencia.
Medidas de mitigación y recomendaciones de seguridad
Para organizaciones que operan LiteLLM en producción, la acción inmediata es actualizar a la versión 1.83.7‑stable o superior, donde la vulnerabilidad CVE‑2026‑42208 ha sido corregida mediante el uso apropiado de consultas parametrizadas y saneamiento de entradas.
En entornos donde el parcheo inmediato no sea viable, los desarrolladores proponen un workaround temporal: establecer disable_error_logs: true en la sección general_settings de la configuración de LiteLLM. Esta medida desactiva la ruta de gestión de errores que desencadena la SQL injection, aunque implica pérdida de visibilidad y no resuelve el problema estructural del código, por lo que debe considerarse solo como mitigación de emergencia.
Además del parche, se recomienda encarecidamente:
- Revisar exhaustivamente los logs de LiteLLM en busca de patrones anómalos y signos de SQL injection en llamadas a endpoints de LLM.
- Rotar todas las claves API y credenciales almacenadas en LiteLLM (OpenAI, Anthropic, AWS Bedrock y otros proveedores).
- Restringir el acceso de red al proxy LiteLLM mediante IP whitelisting, VPN o arquitecturas Zero Trust.
- Incorporar pruebas de seguridad continuas (SAST/DAST) y threat modeling específicas para componentes de infraestructura de IA, no solo para aplicaciones web tradicionales.
La experiencia con GHSA‑r75f‑5x8p‑qvmc refleja una nueva realidad: en software de IA ampliamente confiado, las vulnerabilidades críticas y pre‑autenticación pasan de su divulgación a la explotación en cuestión de horas. Los equipos de seguridad y DevOps que adoptan LLM y AI gateways deben asumir que cualquier fallo público será atacado casi de inmediato, y adaptar en consecuencia sus procesos de actualización, monitorización y gestión de secretos. Invertir hoy en automatización de parches, segmentación de infraestructuras y principios de mínimo privilegio reducirá significativamente el impacto de la próxima vulnerabilidad crítica en el ecosistema de IA.
