Comment la version compromisée de LiteLLM 1.107.0 a infiltré les environnements Python

La version malveillante de LiteLLM 1.107.0 a été diffusée via le Python Package Index (PyPI) et les images Docker officielles, malgré l’absence d’importation explicite de LiteLLM dans le code utilisateur. Selon Microsoft, les attaquants ont exploité une faille dans le workflow de publication en utilisant des crédentials GitHub volés pour rediriger les builds vers un dépôt lookalike nommé Berri-AI/litellm (avec un tiret supplémentaire).

Trois fichiers malveillants (cook.pth, cook.py et sitecustomize.py) ont été injectés dans le package avant sa construction. Ces fichiers, placés dans le répertoire litellm-1.107.0.data/purelib/, sont copiés dans le chemin de bibliothèque Python lors de l’installation. Dès le démarrage de l’interpréteur Python, ils s’exécutent automatiquement, indépendamment de l’application en cours d’utilisation.

Supprimer le package ou son tag de release ne suffit pas pour une récupération complète, car les hooks Python installés persistent dans l’environnement infecté.

Les mécanismes techniques de vol et d’exfiltration des données

Microsoft détaille deux vecteurs d’attaque : un collecteur de crédentials fonctionnant via une extension de chemin (sur Windows) et un chargeur orienté Unix utilisant une configuration spécifique. Le collecteur cible les matériaux d’authentification stockés dans les outils de développeurs, les applications d’IA, les environnements cloud, les navigateurs et les infrastructures, comme le confirment les observations sur Windows et macOS.

Un module de base de données intégré au payload tente de lire les enregistrements des tables LiteLLM_CredentialsTable et LiteLLM_ProxyModelTable, tandis que les modules os et requests de Python sont utilisés pour parser et exfiltrer des fichiers sensibles, incluant les clés SSH, les crédentials AWS, les mots de passe de navigateurs et l’historique des commandes shell. Selon Dev.to, un processus daemon persistant contacte hourly un serveur contrôlé par l’attaquant pour exécuter des commandes arbitraires.

Les risques persistants malgré le retrait de la version infectée

PyPI a retiré la version 1.107.0 de LiteLLM le 21 octobre 2026, et les images Docker latest, main-latest et main-stable ont été marquées comme compromises. Cependant, Microsoft avertit que supprimer le package ou son tag de release ne suffit pas pour une récupération complète, car les hooks Python installés persistent dans l’environnement. Les systèmes utilisant des outils comme pip install --upgrade ou des pipelines CI/CD avec des permissions élevées restent exposés, surtout si les dépendances ne sont pas verrouillées par un digest spécifique (comme litellm==1.106.2).

Endor Labs souligne que la compromission repose sur une ligne malveillante ajoutée dans la configuration Maturin (data = "cook"), absente de la version officielle. Les artefacts infectés incluent les wheels, les images Docker et les distributions source, tous construits à partir d’une révision source altérée.

Ce que cela change ici : implications pour les entreprises et administrations béninoises et ouest-africaines

Pour les entreprises et administrations du Bénin et d’Afrique de l’Ouest utilisant des outils d’IA, des pipelines CI/CD ou des environnements Python pour le développement, cette attaque rappelle l’importance de vérifier systématiquement les dépendances tierces, notamment via des outils comme pip-audit ou des analyses de provenance des conteneurs. Les organisations devraient :

• Mettre à jour immédiatement vers litellm==1.106.2 ou une version antérieure non compromise, en évitant les tags latest ou main dans les registries Docker.
• Verrouiller les versions des dépendances dans les fichiers requirements.txt ou Dockerfile pour éviter les mises à jour automatiques non contrôlées.
• Renforcer les contrôles d’accès aux comptes de développement et aux workflows CI/CD, en limitant les permissions d’approbation et en utilisant des clés SSH ou tokens temporaires.
• Surveiller les comportements anormaux dans les environnements Python, comme des processus persistants ou des connexions sortantes non autorisées vers des serveurs externes.

Les administrations utilisant des infrastructures cloud (AWS, par exemple) ou des outils d’IA locaux doivent aussi auditer leurs configurations pour détecter d’éventuels résidus de cette compromission, notamment dans les tables de crédentials ou les proxys utilisés par LiteLLM.