Check Point identificó vulnerabilidades que permitían a usuarios sin privilegios modificar configuración en tiempo real, extraer credenciales y ejecutar código remoto en uno de los gateways LLM más utilizados del ecosistema.
Check Point Research publicó el hallazgo de múltiples vulnerabilidades de severidad alta en LiteLLM versión 1.77.7, un gateway de código abierto ampliamente adoptado para gestionar comunicación entre aplicaciones y proveedores de modelos de lenguaje. Las fallas, rastreadas como CVE-2026-35029 y CVE-2026-59823, fueron resueltas a partir de la versión 1.83.9. La más crítica permitía a cualquier usuario autenticado — incluyendo cuentas con privilegios mínimos — modificar la configuración del proxy en tiempo de ejecución, lo que derivaba en lectura arbitraria de archivos, takeover de cuentas administrativas y ejecución remota de código mediante módulos Python maliciosos cargados desde almacenamiento en la nube.
Cómo un endpoint administrativo quedó expuesto a usuarios sin privilegios
El núcleo del problema radicó en la ausencia de verificación de autorización en el endpoint /config/update, diseñado para modificar parámetros críticos del proxy durante su operación. Mientras otros endpoints administrativos de LiteLLM — como /invitation/new — verificaban explícitamente que el usuario autenticado poseyera el rol PROXY_ADMIN antes de proceder, el endpoint de actualización de configuración se limitaba a validar que existiera una sesión autenticada válida, sin comprobar el nivel de privilegios asociado.
Esta omisión se combinó con un segundo defecto en la lógica de clasificación de tokens. Cuando un usuario iniciaba sesión en la interfaz web de LiteLLM, el sistema generaba un token temporal asociado al equipo especial litellm-dashboard. La función de autorización clasificaba estos tokens como de tipo «ui» basándose únicamente en el campo team_id, y aplicaba una lista permisiva de rutas permitidas que incluía /config/update. El resultado: cualquier usuario con acceso a la interfaz web podía alcanzar un endpoint que debía estar restringido exclusivamente a administradores.
De la modificación de configuración a la ejecución remota de código
La explotación de la falla de autorización abría tres vectores de ataque concatenados. Primero, un atacante podía modificar variables de entorno en tiempo de ejecución para inyectar rutas de archivos arbitrarias en parámetros de configuración, lo que permitía leer contenido sensible del sistema de archivos del servidor. Segundo, la capacidad de alterar la lista de modelos y sus credenciales asociadas habilitaba el takeover de cuentas administrativas mediante la redefinición de claves API. Tercero — y más grave — la posibilidad de cargar módulos Python personalizados desde almacenamiento en la nube permitía ejecutar código arbitrario en el contexto del proceso del gateway.
Check Point identificó además una vulnerabilidad SSRF separada en la característica Clientside LLM Credentials, que permitía redirigir llamadas API hacia destinos controlados por el atacante y exfiltrar claves de proveedores de modelos. Esta segunda falla operaba independientemente de la primera, pero compartía el mismo patrón de validación insuficiente de entrada en componentes que manejan enrutamiento de solicitudes.
Por qué este caso importa más allá de un parche de seguridad
LiteLLM es un proyecto originado a través de Y Combinator y se posiciona como uno de los gateways LLM de código abierto con mayor adopción en el ecosistema actual. Su función es centralizar la gestión de credenciales, enrutamiento de solicitudes, limitación de tasa y logging entre aplicaciones y múltiples proveedores de modelos — OpenAI, Anthropic, Google, entre otros. Esta posición en la arquitectura lo convierte en un punto de concentración de riesgo: un compromiso exitoso del gateway otorga acceso simultáneo a todas las credenciales de proveedores configuradas y a todo el tráfico de inferencia que atraviesa el sistema.
La naturaleza de las vulnerabilidades identificadas — ausencia de verificación de roles en funciones críticas, validación insuficiente de entrada, lógica de autorización basada en campos controlables por el usuario — no representa innovación técnica por parte de los atacantes. Son defectos de implementación en controles de acceso básicos, del tipo que frameworks de desarrollo web resuelven mediante middlewares estándar desde hace más de una década. Que aparezcan en un componente de infraestructura de IA ampliamente adoptado sugiere que la velocidad de desarrollo en el ecosistema LLM está superando la aplicación de prácticas de seguridad establecidas.
Exposición en América Latina por dependencia de infraestructura compartida
La adopción de gateways LLM en la región sigue el patrón de concentración en proveedores de código abierto observado en otras capas de infraestructura cloud. Empresas en Brasil, México y Argentina que implementan capacidades de IA generativa recurren frecuentemente a LiteLLM y proyectos similares para abstraer la complejidad de integrar múltiples proveedores de modelos, especialmente en contextos donde el costo de licencias empresariales de soluciones propietarias resulta prohibitivo. Esta dependencia estructural implica que una vulnerabilidad en el gateway afecta simultáneamente a múltiples organizaciones que comparten la misma base de código, sin que exista necesariamente visibilidad centralizada del riesgo.
El caso es representativo de un problema más amplio en la región: la adopción acelerada de componentes de infraestructura de IA sin capacidad interna para auditar su seguridad. A diferencia de vulnerabilidades en aplicaciones de cara al usuario — donde el impacto es visible y genera presión para remediar — las fallas en componentes de middleware como gateways LLM pueden permanecer sin detectar durante meses, exponiendo credenciales y datos de inferencia sin que los equipos de seguridad tengan indicadores claros de compromiso. La ausencia de logs de auditoría granulares en muchas implementaciones de LiteLLM agrava este problema: un atacante que explote la falla de /config/update puede modificar configuración sin dejar rastro evidente en los registros estándar del sistema.
Nuestro análisis
Este caso confirma un patrón que ya observamos en incidentes previos de infraestructura de IA: la brecha entre la madurez funcional de las herramientas y la madurez de sus controles de seguridad. LiteLLM implementa características avanzadas de enrutamiento, fallback entre proveedores y gestión de cuotas, pero falló en aplicar verificación de roles en un endpoint que modifica configuración crítica en tiempo de ejecución. La comparación con otros endpoints del mismo código — donde la verificación sí está presente — indica que no se trata de desconocimiento técnico, sino de inconsistencia en la aplicación de controles durante el desarrollo iterativo.
La resolución de las vulnerabilidades a partir de la versión 1.83.9 cierra el vector específico, pero no resuelve el problema de fondo: la ausencia de revisión de seguridad sistemática en componentes de infraestructura de IA de código abierto. A diferencia de proyectos con décadas de madurez — donde existe un proceso establecido de disclosure, análisis de impacto y coordinación de parches — el ecosistema LLM opera todavía con procesos ad hoc. La pregunta que queda abierta es cuántos componentes similares, adoptados a la misma velocidad y con el mismo nivel de escrutinio, están operando en producción con defectos equivalentes sin descubrir.