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 a través de PyPI y determinadas etiquetas oficiales de contenedores. La versión recomendada para revertir es la 1.106.2, y quienes hayan instalado o ejecutado los artefactos afectados deben ir más allá de una actualización convencional: aislar el entorno, reconstruirlo desde una base limpia y rotar las credenciales accesibles.

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 suministrada menciona paquetes de PyPI e imágenes de Docker, entre ellas latest y main-stable, mientras que análisis de seguridad de Wiz y Aikido también incluyen v1.107.0 y main-latest.

El alcance importa 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 podrían haber descargado una compilación contaminada como parte de sus prácticas habituales de despliegue, sin realizar una actualización explícita de versión.

Dentro de este alcance reportado, estos son los datos más relevantes hasta el momento:

Según los reportes disponibles, los plazos de limpieza no fueron idénticos en todos los canales. Un fragmento de un issue de GitHub vinculado a BerriAI/litellm indicó 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 eliminadas. Esto respalda el panorama general del incidente, aunque no permite establecer una única hora final de limpieza.

Por qué la carga útil reportada era especialmente riesgosa

JFrog afirma que el wheel malicioso de LiteLLM utilizaba un hook de inicio de Python, lo que habría permitido ejecutar la carga útil al iniciarse Python en un entorno afectado, sin esperar a que una aplicación importara LiteLLM de forma directa. En el fragmento disponible, JFrog atribuye este comportamiento a un archivo cook.pth procesado durante la inicialización normal del sitio de Python.

De confirmarse ese mecanismo, el perímetro de exposición sería más amplio que el de una simple 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 suministrada señala que los datos sensibles en riesgo incluían credenciales de nube, claves API de IA y claves privadas SSH. Por separado, reportes de marzo de 2026 resumieron una publicación de Andrej Karpathy que describía un ataque más amplio contra LiteLLM en PyPI, con robo de claves SSH, credenciales de nube, configuraciones de Kubernetes, credenciales de Git, variables de entorno, claves de CI/CD y contraseñas de bases de datos. Sin embargo, aquel reporte anterior no establecía el alcance de las etiquetas de Docker ni la lista exacta de artefactos 1.107.0 del incidente de octubre.

Qué deberían 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, reconstruirlo desde un entorno limpio y rotar las credenciales a las que ese entorno pudiera 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 en adelante, pero no resuelve si los secretos ya quedaron expuestos mientras el wheel o la imagen contaminados estuvieron activos.

Para los operadores, el umbral práctico para actuar es amplio: quien haya instalado litellm==1.107.0, descargado una etiqueta flotante reportada como afectada o iniciado Python en un entorno expuesto debería considerar que el host o contenedor fue potencialmente 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 que fuera accesible desde ese entorno de ejecución.