LiteLLM 1.107.0: comprobar la exposición a artefactos sin reiniciar un Python comprometido

Qué es

Estado al 25 de octubre de 2026. El aviso de incidente de LiteLLM identifica la versión maliciosa 1.107.0 del 21 de octubre. Volver a consultar ese aviso y su informe oficial de causa raíz antes de iniciar la recuperación. Esta descripción se basa en la corrección del aviso del 23 de octubre a las 21:50 UTC, el informe de causa raíz publicado el 23 de octubre y la revisión de OSV con marca de tiempo del 21 de octubre a las 22:01:01 UTC.

El aviso del proveedor indica estos intervalos de distribución, todos en UTC del 21 de octubre: paquetes wheel de PyPI, 11:39:51–13:23; Docker Hub, 11:46:56–14:20; GHCR, desde las 11:46:56 hasta que dejaron de estar disponibles, a más tardar a las 13:51. Las etiquetas de contenedor eran v1.107.0, latest, main-latest y main-stable. Las copias almacenadas en cache pueden ejecutarse más tarde.

Por qué importa

OSV MAL-2026-2144 describe un robo de credenciales y un cargador de código remoto que se activaba al iniciar Python, sin que ninguna aplicación tuviera que importar LiteLLM. Su registro combina información de incidentes anteriores con los hallazgos de octubre; utilizar la lista de artefactos afectados del proveedor, en lugar de interpretar la entrada general de versiones de OSV como una indicación de que todas las versiones son maliciosas.

La investigación oficial sustituye la teoría inicial sobre los registros de despliegue: una clave maestra expuesta que no se había revocado permitió acceder a un servicio de agentes independiente, que devolvió el token de GitHub de uno de los propietarios. Las identidades robadas se utilizaron después para comprometer el proceso de publicación. Por tanto, además de sustituir el paquete, es necesario recuperar los repositorios y las cuentas.

Cómo aplicarlo

• Aislar los equipos afectados y pausar la publicación. Conservar los archivos de bloqueo de dependencias, los registros de instalación, las referencias de imágenes y los registros de CI. Anotar si un artefacto se descargó, se instaló o se ejecutó; un inventario actual de dependencias no permite reconstruir entornos eliminados.
• Inspeccionar una copia de solo lectura del sistema de archivos con herramientas de confianza. Por ejemplo, find /mnt/evidence -type d -name 'litellm-1.107.0.dist-info' localiza los metadatos instalados sin iniciar el intérprete sospechoso. Contrastar cook.pth, cook.py y sitecustomize.py con los indicadores del aviso. Los nombres de archivo genéricos por sí solos no demuestran que el contenido sea malicioso.
• Desde un entorno de administración de confianza, utilizar docker image inspect IMAGE_ID para inspeccionar los metadatos locales de las imágenes conservadas. Comparar los resúmenes criptográficos del registro con el aviso del proveedor, incluida la variante correcta de GHCR. El valor actual de una etiqueta mutable no demuestra qué ejecutaba un contenedor anterior; si faltan los metadatos del resumen criptográfico del registro, hacen falta registros de despliegue o del registro de imágenes.
• No ejecutar pip ni Python dentro del entorno sospechoso. Reconstruirlo a partir de componentes limpios. La versión que el proveedor indica fijar para recuperarse de este incidente es litellm==1.106.2; solo en un entorno nuevo, python3 -m pip install 'litellm==1.106.2' expresa esa selección de versión. Revisar el conjunto completo de dependencias y los avisos actuales antes de volver a conectarlo.
• Revocar y sustituir desde un equipo limpio las credenciales accesibles: credenciales de publicación y de repositorios, acceso a la nube, contraseñas de bases de datos, claves de proveedores y secretos de aplicaciones. Revisar su uso desde el primer momento en que pudo producirse la exposición. Antes de restablecer el servicio, comparar los artefactos registrados del entorno de sustitución con los componentes aprobados para la recuperación.

Trampas

Desinstalar un paquete no revierte el robo de credenciales ni demuestra que se haya eliminado la persistencia. La ausencia de indicadores temporales no demuestra que el entorno sea seguro. La versión fijada para la recuperación aborda este incidente, no todas las vulnerabilidades ajenas a él; volver a comprobarla en lugar de tratarla como una garantía de seguridad permanente.