Vulnerabilidad Crítica de Inyección SQL en LiteLLM Gateway Explotada en la Naturaleza
Una vulnerabilidad crítica de inyección SQL, rastreada como **CVE-2026-42208**, está siendo explotada activamente en la puerta de enlace de modelo de lenguaje grande (LLM) de código abierto **LiteLLM**. Los atacantes están aprovechando la falla para acceder y modificar información sensible, incluidas claves API y credenciales.

Investigadores de ciberseguridad están reportando la explotación activa de una vulnerabilidad crítica en **LiteLLM**, una puerta de enlace LLM de código abierto. La vulnerabilidad, identificada como **CVE-2026-42208**, permite a los atacantes realizar ataques de inyección SQL contra la puerta de enlace.
## Detalles de la Vulnerabilidad
La falla reside en el paso de verificación de clave API del proxy dentro de **LiteLLM**. Al enviar una cabecera `Authorization` especialmente diseñada a cualquier ruta de API LLM, un atacante no autenticado puede explotar esta vulnerabilidad. Esto les otorga la capacidad de leer y modificar datos dentro de la base de datos del proxy.
Según el [aviso de seguridad](http://github.com/BerriAI/litellm/security/advisories/GHSA-r75f-5x8p-qvmc) del mantenedor, los actores de amenazas podrían usar esta vulnerabilidad para "acceso no autorizado al proxy y las credenciales que gestiona".
## Remediación
Se lanzó una corrección para esta vulnerabilidad en la versión 1.83.7 de **LiteLLM**. Esta actualización reemplaza la concatenación de cadenas con consultas parametrizadas, mitigando efectivamente el riesgo de inyección SQL.
Dado que **LiteLLM** almacena datos sensibles como claves API, claves virtuales y maestras, y secretos de entorno/configuración, la explotación exitosa podría llevar a brechas de seguridad significativas.
## Resumen de LiteLLM
**LiteLLM** es una capa intermedia de proxy/SDK ampliamente utilizada que proporciona una API unificada para llamar a varios modelos de IA. Simplifica la gestión de múltiples modelos para desarrolladores de aplicaciones y plataformas LLM. El proyecto cuenta con un importante seguimiento comunitario, con 45k estrellas y 7.6k forks en [GitHub](https://github.com/BerriAI/litellm).
Notablemente, **LiteLLM** fue recientemente objetivo de un [ataque de cadena de suministro](https://www.bleepingcomputer.com/news/security/popular-litellm-pypi-package-compromised-in-teampcp-supply-chain-attack/) donde los hackers de **TeamPCP** comprometieron el paquete PyPI, desplegando un infostealer para recolectar credenciales, tokens y secretos de sistemas infectados.
## Explotación Activa
Investigadores de **Sysdig** han informado que la explotación de **CVE-2026-42208** comenzó aproximadamente 36 horas después de la divulgación pública de la vulnerabilidad el 24 de abril.
Los ataques observados involucraron solicitudes diseñadas enviadas al endpoint `/chat/completions`, utilizando una cabecera maliciosa `Authorization: Bearer`. Estas solicitudes apuntaron a tablas específicas que contenían claves API, credenciales de proveedor (por ejemplo, **OpenAI**, **Anthropic**, **Bedrock**), datos de entorno y configuraciones.
**Sysdig** señaló que los atacantes exhibieron una clara comprensión de la estructura de la base de datos, apuntando directamente a tablas que contenían información sensible. En la segunda fase del ataque, el actor de amenazas rotó las direcciones IP, probablemente con fines de evasión, y refinó sus intentos de inyección SQL basándose en la información obtenida en la fase inicial.
Si bien el cronograma de explotación no fue tan rápido como la [reciente falla en Marimo](https://www.bleepingcomputer.com/news/security/critical-marimo-pre-auth-rce-flaw-now-under-active-exploitation/), los ataques fueron altamente dirigidos y específicos, según **Sysdig**.
## Recomendaciones
Se insta a los profesionales de seguridad a tratar cualquier instancia expuesta de **LiteLLM** que ejecute versiones vulnerables como potencialmente comprometida. Es crucial rotar todas las claves API virtuales, claves maestras y credenciales de proveedor almacenadas en instancias de **LiteLLM** expuestas a Internet.
Para aquellos que no puedan actualizar inmediatamente a **LiteLLM** 1.83.7 o posterior, hay una solución alternativa disponible: establecer `disable_error_logs: true` en `general_settings` para bloquear la ruta a través de la cual las entradas maliciosas pueden alcanzar la consulta vulnerable.
