En otro ejemplo más de actores de amenazas que se subieron rápidamente al tren de la explotación, una falla de seguridad crítica recientemente revelada en el paquete LiteLLM Python de BerriAI fue explotada activamente en la naturaleza dentro de las 36 horas posteriores a que el error se hiciera público.
Esta vulnerabilidad, rastreada como CVE-2026-42208 (puntuación CVSS: 9,3), es una inyección SQL que puede explotarse para modificar la base de datos proxy LiteLLM subyacente.
«La consulta de la base de datos utilizada durante la verificación de la clave API del proxy mezclaba el valor de la clave especificada por la persona que llama en el texto de la consulta en lugar de pasarlo como un parámetro separado», dijeron los mantenedores de LiteLLM en una alerta la semana pasada.
«Un atacante no autenticado podría enviar un encabezado de Autorización especialmente diseñado a cualquier ruta API de LLM (como POST /chat/completions) y acceder a esta consulta a través de la ruta de manejo de errores del proxy. El atacante podría leer datos de la base de datos del proxy y potencialmente modificarlos, lo que podría conducir a un acceso no autorizado al proxy y a las credenciales que administra».
Esta deficiencia afecta a las siguientes versiones:
Aunque esta vulnerabilidad se abordó en la versión estable 1.83.7 lanzada el 19 de abril de 2026, el primer intento de explotación se registró el 26 de abril a las 16:17 UTC, aproximadamente 26 horas y 7 minutos después de que el aviso de GitHub fuera indexado en la base de datos global de avisos de GitHub. Según Sysdig, la actividad de inyección SQL se originó en la dirección IP 65.111.27(.)132.
«La actividad maliciosa se dividió en dos fases, iniciada por el mismo operador entre dos IP de salida adyacentes, seguida de una breve investigación de un punto final de gestión de claves no autenticado», dijo el investigador de seguridad Michael Clarke.
Específicamente, los atacantes desconocidos supuestamente atacaron tablas de bases de datos como ‘litellm_credentials.credential_values’ y ‘litellm_config’ que contienen información relacionada con claves de proveedores de modelos de lenguaje grande (LLM) y entornos de ejecución de proxy. No se observaron sondas para tablas como ‘litellm_users’ o ‘litellm_team’.
Esto sugiere que los atacantes no sólo conocían estas tablas, sino que también apuntaban a tablas que contenían secretos confidenciales. En la segunda fase del ataque, observada 20 minutos después, los atacantes utilizaron una dirección IP diferente (‘65.111.25(.)67’) y esta vez explotaron su acceso para realizar un sondeo similar.
LiteLLM es un popular software de puerta de enlace de IA de código abierto con más de 45.000 estrellas y 7.600 bifurcaciones en GitHub. El mes pasado, el proyecto fue objeto de un ataque a la cadena de suministro orquestado por el grupo de hackers TeamPCP para robar credenciales e información confidencial de usuarios intermedios.
«Una sola línea litellm_credentials a menudo incluye una clave de organización OpenAI con un límite de gasto mensual de cinco dígitos, una clave de consola Anthropic con privilegios de administrador del espacio de trabajo y credenciales de AWS Bedrock IAM», dijo Sysdig. «El alcance de una extracción exitosa de una base de datos es más similar al compromiso de una cuenta en la nube que a una inyección SQL típica de una aplicación web».
Recomendamos que los usuarios actualicen sus instancias a la última versión. Si esta no es una opción inmediata, se recomienda a los administradores configurar «disable_error_logs: true» en «general_settings» para eliminar la ruta a través de la cual entradas no confiables pueden llegar a consultas vulnerables.
«La vulnerabilidad LiteLLM (GHSA-r75f-5x8p-qvmc) continúa el patrón modal de los avisos de infraestructura de IA: un aviso de estrella en software de cinco dígitos en el que los operadores confían para gestionar de forma centralizada las credenciales críticas, de autenticación previa y de nivel de nube», añadió Sysdig.
«La ventana de explotación de 36 horas es consistente con el colapso generalizado documentado por Zero Day Clock, y las acciones del operador que registramos (nombres textuales de las tablas Prisma, orientación de tres tablas, enumeración intencional del recuento de columnas) indican que la explotación ya no esperará a una PoC pública. El esquema de código abierto y de asesoramiento fue finalmente suficiente».
Source link
