BRIEFING DE SEGURIDAD · 08.07.2026 DEENFRES

Casos de estudio

LiteLLM CVE-2026-42208: Acceso no autorizado a bases de datos

Por Alec Chizhik · 29 de abril de 2026 · 8 min de lectura

Una inyección SQL en una capa proxy de IA no es una vulnerabilidad web clásica. Cualquier persona que utilice LiteLLM como capa de enrutamiento y no haya aplicado aún la corrección, expone potencialmente todas las claves API de los proveedores de LLM, así como cada prompt que haya transitado por el proxy.

Lo más importante en resumen

  • CVSS 9,3 – Crítico. CVE-2026-42208 permite a atacantes no autenticados modificar la base de datos a través de la interfaz de administración del proxy LiteLLM.
  • Nueva superficie de ataque. Los proxies de IA como LiteLLM almacenan claves API de proveedores, configuraciones de enrutamiento de modelos y registros de prompts, todo ello en una base de datos.
  • Sin necesidad de autenticación. El ataque de inyección SQL no requiere autenticación: el punto de acceso está expuesto si LiteLLM se ejecuta sin firewall.
  • Respuesta a incidentes diferente. Las guías clásicas para aplicaciones web no son aplicables; el alcance del impacto afecta a todas las cuentas de proveedores de LLM aguas abajo.
  • Medida inmediata. Actualice a la versión corregida de LiteLLM, renueve todas las claves API de los proveedores y asegure el punto de acceso de administración del proxy.

¿Qué es LiteLLM? LiteLLM es una biblioteca open source en Python y un servidor proxy que proporciona una API unificada para más de 100 proveedores de LLM: OpenAI, Anthropic, Azure OpenAI, Google Gemini, Bedrock, Groq y muchos otros. Las empresas utilizan LiteLLM como middleware entre su aplicación y los distintos proveedores de modelos: gestión centralizada de claves, seguimiento del uso, limitación de velocidad y balanceo de carga. En resumen: LiteLLM es precisamente la herramienta que mantiene a menudo invisiblemente unidas las infraestructuras modernas de IA.

La vulnerabilidad reside en el punto de acceso de la API de administración del proxy LiteLLM. Gracias a la inyección SQL, un atacante no autenticado puede modificar directamente la base de datos que LiteLLM utiliza para la configuración y el registro. Esto no es baladí: esta base de datos contiene generalmente las claves API de todos los proveedores configurados, las reglas de enrutamiento y, según la configuración, los prompts y respuestas almacenados en caché.

9,3
Puntuación CVSS
Crítico – CVE-2026-42208

0
Autenticación requerida para la explotación
vector de ataque no autenticado

100+
Proveedores de LLM accesibles vía LiteLLM
soportados en el ecosistema LiteLLM

Por qué las capas proxy de IA requieren una respuesta a incidentes diferente

Una inyección SQL clásica en una aplicación web es grave: generalmente implica datos de clientes, tokens de sesión o credenciales de acceso. En un proxy de IA, el potencial de daño es estructuralmente diferente:

  1. Claves API de proveedores con alto impacto: LiteLLM gestiona las claves de todos los proveedores configurados. Una clave de OpenAI robada provoca un uso no controlado de la API a costa de la empresa, así como un acceso potencial a los datos de todos los proyectos de OpenAI asociados a esa cuenta. Una clave de Anthropic comprometida otorga un acceso similar.
  2. Manipulación del enrutamiento: Si un atacante obtiene acceso de escritura a la base de datos de LiteLLM, puede modificar las reglas de enrutamiento y redirigir los prompts a un endpoint externo. Se trata de una forma de exfiltración de datos que a menudo evade las reglas SIEM clásicas.
  3. Los registros de prompts como datos sensibles: Muchos despliegues de LiteLLM registran los prompts y respuestas con fines de depuración y seguimiento del uso. En la práctica, estos registros contienen fragmentos de documentos internos, solicitudes de clientes y datos comerciales confidenciales.
  4. Impacto aguas abajo en las aplicaciones: Si un atacante modifica la configuración de enrutamiento, todas las aplicaciones que utilizan el proxy pueden comenzar a recibir respuestas de un modelo incorrecto. Esto es difícil de detectar y puede provocar comportamientos erróneos en sistemas en producción.

Lo que los equipos DevSecOps deben verificar inmediatamente

Medida inmediata Por qué es crítico
Actualizar LiteLLM a la versión corregida Cierra el vector de inyección SQL
Regenerar todas las claves API de los proveedores Las claves robadas seguirían siendo válidas de lo contrario
Eliminar el acceso público al endpoint de administración desde Internet La API de administración nunca fue diseñada para acceso público
Revisar los registros de LiteLLM en busca de cambios anómalos en el enrutamiento Indica si un atacante ya ha modificado el enrutamiento
Verificar las cuentas de los proveedores para detectar un uso inusual Un uso abusivo de la clave API genera costes y deja rastros

El endpoint de administración es el problema decisivo: LiteLLM fue diseñado para uso interno. En los despliegues en producción, el proxy suele ejecutarse en el puerto 4000, con la interfaz de administración expuesta. La segmentación de red o un proxy inverso que bloquee el puerto de administración debería ser una configuración estándar, pero no lo es.

Preguntas frecuentes

Cada pregunta está bloqueada. Un toque desbloquea la respuesta.

¿Qué versiones de LiteLLM se ven afectadas por el CVE-2026-42208?

La vulnerabilidad afecta a las versiones del proxy LiteLLM anteriores a la versión corregida publicada tras la divulgación del CVE. El límite exacto de versión debe consultarse en la documentación oficial del CVE y en el repositorio GitHub de LiteLLM. Los usuarios que hayan instalado LiteLLM mediante pip pueden actualizar a la versión actual con pip install –upgrade litellm.

¿Cómo comprobar si mi endpoint de administración de LiteLLM es accesible desde Internet?

Compruebe si el puerto 4000 del host LiteLLM es accesible desde el exterior. Un método sencillo: curl http://[host]:4000/health desde una red externa. Si el endpoint responde, está expuesto. El endpoint de administración solo debería ser accesible mediante redes internas o una VPN. Utilizar Nginx como proxy inverso con una regla de bloqueo de IPs externas en las rutas de administración es la medida de endurecimiento más rápida.

¿Qué hacer si no se sabe si ha ocurrido un ataque?

Consulte los registros de la base de datos LiteLLM buscando llamadas API no autenticadas hacia el endpoint afectado y modificaciones inusuales de la configuración de enrutamiento. Verifique las cuentas de los proveedores (OpenAI, Anthropic, etc.) para detectar cualquier uso de la API desde direcciones IP desconocidas. En caso de duda: cambie todas las claves y, en el peor de los casos, asuma que las claves de acceso y los registros de prompts han sido comprometidos.

¿Es LiteLLM un caso aislado o se trata de un problema generalizado entre los proxies de IA?

Los proxies de IA y las pasarelas LLM constituyen una categoría de software relativamente nueva: LiteLLM, OpenRouter, PortKey, Helicone y otros. Surgieron rápidamente para responder a la necesidad de APIs LLM unificadas, sin haber atravesado el ciclo de maduración en seguridad que ya conocen las categorías de software más antiguas. Esto lo convierte en un punto ciego estructural para muchos equipos de seguridad, que consideran la infraestructura de IA como «una simple API».

¿Qué reglas de monitorización deberían implementarse para los despliegues de LiteLLM?

Cuatro reglas de monitorización útiles: (1) Alerta en caso de llamada API al endpoint de administración desde direcciones IP externas. (2) Alerta en caso de modificación de la configuración de enrutamiento en la base de datos LiteLLM. (3) Detección de anomalías en el uso de la API del proveedor: desviaciones significativas respecto al consumo base. (4) Alerta si los registros de LiteLLM dejan de generarse: un atacante con acceso podría desactivar los registros.

Selección de lecturas recomendadas por la redacción

Más contenidos de la red MBF Media

cloudmagazinLey de IA de la UE para proveedores SaaS: qué significa concretamente la clasificación de alto riesgo a partir de agostoDigital ChiefsSeguridad del IoT industrial en 2026: los dispositivos edge ahora incluidos en los informes de dirección y el ámbito de auditoría NIS2

Lectura adicional

Una revista de Evernine Media GmbH