Los reportes actuales y análisis de investigadores de seguridad indican que LiteLLM 1.107.0 fue una versión maliciosa distribuida el 21 de octubre de 2026 mediante PyPI y ciertas etiquetas oficiales de contenedores. La versión que se reporta como segura para revertir es la 1.106.2, y la respuesta recomendada para quienes instalaron o ejecutaron los artefactos afectados va más allá de una actualización habitual: aislar el entorno, reconstruirlo desde una base limpia y rotar las credenciales a las que podía acceder.

Qué artefactos de LiteLLM habrían sido comprometidos

Los reportes actuales apuntan a LiteLLM 1.107.0 como la versión comprometida, con una exposición que abarcaría tanto el paquete de PyPI como imágenes oficiales de contenedores. La alerta proporcionada menciona paquetes de PyPI e imágenes de Docker, incluidas latest y main-stable, mientras que análisis de seguridad de Wiz y Aikido también citan v1.107.0 y main-latest.

El alcance es importante porque algunos usuarios afectados podrían no haber elegido directamente la versión 1.107.0. Los equipos que dependían de etiquetas de imagen móviles pudieron descargar una compilación contaminada como parte de sus prácticas normales de despliegue, sin realizar un cambio explícito de versión.

Dentro del alcance reportado, estos son los datos más relevantes hasta ahora:

Los reportes disponibles no coinciden sobre el momento de la limpieza en todos los canales. Un fragmento de una incidencia de GitHub vinculada a BerriAI/litellm señalaba que PyPI ya había sido limpiado, mientras que las etiquetas flotantes de Docker seguían infectadas en un momento del 21 de octubre; posteriormente, Wiz describió que esas etiquetas habían sido retiradas. Esto respalda el panorama general del incidente, aunque no permite establecer una hora final única para la limpieza.

Por qué la carga reportada era particularmente riesgosa

JFrog afirma que la rueda maliciosa de LiteLLM utilizaba un gancho de inicio de Python, lo que permitiría ejecutar la carga al arrancar Python en un entorno afectado, sin esperar a que una aplicación importara LiteLLM directamente. En el fragmento disponible, JFrog atribuye ese comportamiento a un archivo cook.pth procesado durante la inicialización normal del sitio de Python.

De haberse utilizado ese mecanismo, el perímetro de exposición sería más amplio que una llamada a una biblioteca comprometida. Iniciar Python dentro del entorno afectado podría activar la lógica de robo de credenciales, lo que ayuda a explicar por qué las recomendaciones se centran en la contención y la rotación de secretos, en lugar de limitarse a reemplazar una versión del paquete.

La alerta proporcionada señala que entre los datos sensibles en riesgo estaban las credenciales en la nube, las claves de API de IA y las claves privadas de SSH. Un reporte independiente de marzo de 2026 resumió una publicación de Andrej Karpathy que describía un ataque más amplio contra LiteLLM en PyPI, capaz de robar claves SSH, credenciales en la nube, configuraciones de Kubernetes, credenciales de Git, variables de entorno, claves de CI/CD y contraseñas de bases de datos. Sin embargo, ese reporte anterior no estableció el alcance de las etiquetas de Docker ni la lista exacta de artefactos 1.107.0 del incidente de octubre.

Qué deben hacer ahora los usuarios afectados

La respuesta reportada consiste en dejar de usar la versión 1.107.0, revertir o fijar la versión 1.106.2, aislar cualquier host o contenedor que haya instalado o ejecutado el artefacto afectado, reconstruir desde un entorno limpio y rotar las credenciales a las que ese entorno podía acceder. Tanto Aikido como JFrog plantean el problema en función de si el paquete o la imagen maliciosos fueron instalados o ejecutados, no de si siguen disponibles actualmente.

La diferencia es importante. Una actualización sobre el entorno existente puede eliminar la versión maliciosa hacia adelante, pero no resuelve si los secretos ya quedaron expuestos mientras la rueda o imagen contaminada estaba activa.

Para los operadores, el umbral práctico de acción es amplio: quien haya instalado litellm==1.107.0, descargado una etiqueta flotante reportada como afectada o iniciado Python en un entorno expuesto debe considerar que el host o contenedor pudo haber sido comprometido. Los reportes disponibles respaldan reconstruir desde imágenes o entornos limpios y rotar cualquier credencial de nube, API, SSH, base de datos o similar a la que pudiera acceder ese entorno de ejecución.