Los informes disponibles y los 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 de determinadas etiquetas oficiales de contenedores. La versión segura recomendada para revertir es la 1.106.2. Para quienes instalaron o ejecutaron los artefactos afectados, la respuesta debe 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 informes actuales apuntan a LiteLLM 1.107.0 como la versión comprometida, con una exposición que habría afectado tanto al paquete de PyPI como a imágenes oficiales de contenedores. La alerta facilitada menciona paquetes de PyPI e imágenes Docker, incluidas latest y main-stable, mientras que los análisis de seguridad de Wiz y Aikido también señalan v1.107.0 y main-latest.

Este 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 habituales de despliegue, sin realizar una actualización explícita de versión.

Dentro del alcance comunicado, estos son los datos más relevantes disponibles:

Según la información disponible, la limpieza no se produjo al mismo tiempo en todos los canales. Un fragmento de una incidencia de GitHub vinculada a BerriAI/litellm indicaba que PyPI ya se había limpiado, mientras que las etiquetas flotantes de Docker seguían infectadas en un momento dado del 21 de octubre; posteriormente, Wiz describió que esas etiquetas fueron retiradas. Esto respalda el panorama general del incidente, aunque no permite fijar una única hora definitiva de limpieza.

Por qué la carga útil denunciada era especialmente peligrosa

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

De confirmarse este mecanismo, el perímetro de exposición sería más amplio que el de una simple llamada a una biblioteca comprometida. Iniciar Python en el 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, y no solo en sustituir una versión del paquete.

La alerta facilitada indica que entre los datos sensibles en riesgo figuraban credenciales de servicios en la nube, claves de API de IA y claves privadas SSH. Por separado, informaciones 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 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, aquella información previa no establecía el alcance de las etiquetas Docker ni la lista exacta de artefactos 1.107.0 correspondientes al incidente de octubre.

Qué deben hacer ahora los usuarios afectados

La respuesta comunicada 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 instalase o ejecutase el artefacto afectado, reconstruir desde un entorno limpio y rotar las credenciales a las que ese entorno pudiera acceder. Tanto Aikido como JFrog enfocan el problema en si el paquete o la imagen maliciosos llegaron a instalarse o ejecutarse, y no en si siguen disponibles actualmente.

Esta distinción es importante. Una actualización sobre el entorno existente puede eliminar la versión maliciosa de cara al futuro, pero no determina si los secretos ya quedaron expuestos mientras la rueda o la imagen contaminadas estuvieron activas.

Para los operadores, el umbral práctico de actuación es amplio: cualquiera que haya instalado litellm==1.107.0, descargado una de las etiquetas flotantes supuestamente afectadas o iniciado Python en un entorno expuesto debe considerar que el host o contenedor podría estar comprometido. La información disponible respalda 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.