🔥 Le paquet LiteLLM a été piraté. Si vous travaillez avec des API LLM, il est temps de vous inquiéter.

Hier, dans l'écosystème Python, une attaque de la chaîne d'approvisionnement exemplaire a eu lieu. Le paquet litellm a été compromis — une bibliothèque avec 97 millions de téléchargements par mois, qui se trouve actuellement sous le capot de nombreux projets IA.

La version infectée 1.82.8 a été publiée sur PyPI. Elle contenait soigneusement un fichier litellm_init.pth avec une charge utile en base64 qui faisait une chose simple : aspirer votre machine à la recherche de secrets et les envoyer à un serveur distant, tout en s'auto-répliquant.

La liste des éléments "volés" comprend tout ce que le script a pu atteindre :
▫️ Clés SSH
▫️ Identifiants AWS/GCP/Azure
▫️ Configurations Kubernetes
▫️ Fichiers .env (bonjour vos jetons OpenAI)
▫️ Historique du terminal et mots de passe de bases de données
▫️ Clés SSL privées et portefeuilles crypto

De plus, vous n'aviez même pas besoin d'écrire pip install litellm pour donner vos clés de production. Il suffisait d'installer ou de mettre à jour un outil qui le tire comme dépendance transitive. Par exemple, vous mettez à jour le populaire dspy (qui a litellm>=1.64.0 dans ses requirements) — bienvenue au club des piratés.

Mais dans toute cette histoire, il y a un détail incroyable.

Ce qui a sauvé l'industrie d'une catastrophe mondiale, c'est que le hacker était un mauvais codeur. 🤡
Le malware était si mal écrit qu'il provoquait une fuite de mémoire. Un gars utilisait un plugin dans Cursor qui a tiré en arrière-plan la version récente de litellm. Le script a consommé toute la RAM et a planté le système. Grâce à cela, la version infectée n'est restée sur PyPI que moins d'une heure avant d'être supprimée.

Si l'attaquant avait correctement testé son code, l'exploit aurait pu rester des semaines. La moitié des startups IA auraient fermé demain à cause des bases de clients divulguées et des budgets cloud vidés.

Andrej Karpathy a donné son avis à ce sujet : le paradigme classique de développement « nous construisons des pyramides avec des briques de dépendances » devient une vulnérabilité fatale dans les réalités modernes. On nous a appris pendant des décennies le modèle académique : « ne réinvente pas la roue, réutilise, prends une bibliothèque prête à l'emploi ».
Dans la réalité actuelle des chaînes d'approvisionnement, cela équivaut à jouer à la roulette russe. Chaque fois que vous ajoutez une nouvelle dépendance à votre projet, vous importez tout son arbre jusqu'à la dixième génération. Et quelque part là-dedans, il peut y avoir un mainteneur mécontent ou un compte piraté.

Le paradigme change. Au lieu de tirer une énorme bibliothèque pour quelques fonctions utilitaires, il est désormais plus sûr et plus pragmatique de simplement copier-coller (ou générer via LLM) le morceau de code nécessaire et de le verrouiller dans votre propre dépôt. 🤷‍♂️