Imaginez : vous téléchargez un programme depuis un dépôt officiel. Vous vérifiez sa signature numérique. Vous installez la mise à jour. Et de vos propres mains, vous exécutez du code malveillant sur votre serveur.
Ce n'grâce pas un scénario de science-fiction. C'est exactement le type de danger qu'a illustré l'attaque contre LiteLLM en octobre 2026.
Dans notre précédente enquête « Linux sans mot de passe, passerelles IA menacées : quels serveurs sont réellement protégés ? », nous avons analysé les vulnérabilités des systèmes d'exploitation et des passerelles d'intelligence artificielle.
Il apparaît désormais un fait encore plus marquant : parfois, un attaquant n'a même pas besoin de pirater votre serveur. Il lui suffit de le tromper pour qu'il accepte une mise à jour corrompue comme s'il s'agissait de la légitime.
Tout a commencé par une simple clé oubliée
Le 27 mai 2026, une clé administrative du système interne a accidentellement fuité dans le dépôt GitHub public des développeurs de LiteLLM.
L'erreur a été remarquée rapidement. Le fichier a été supprimé au bout d'environ trois heures.
Mais la clé elle-même n'a pas été révoquée.
Et une copie de celle-ci est restée stockée dans l'historique de GitHub.
Plus de quatre mois ont passé.
Le 10 octobre, un attaquant a exploité cette clé oubliée pour obtenir un accès à la plateforme expérimentale d'agents IA de LiteLLM.
Il y a découvert un autre cadeau : un jeton d'accès GitHub disposant des privilèges de propriétaire de l'organisation.
Un seul secret oublié a ouvert la porte à toute l'infrastructure de développement.
Comment la version officielle a été compromise
Une fois l'accès à GitHub obtenu, l'attaquant a modifié le processus de construction (build) du logiciel.
Normalement, le système était configuré pour compiler LiteLLM à partir du dépôt légitime BerriAI/litellm.
Mais l'attaquant a préparé une adresse similaire : Berri-AI/litellm.
La différence est presque imperceptible.
Il a ensuite modifié les paramètres de compilation afin que son propre code source soit utilisé à la place du vrai.
La publication d'une nouvelle version nécessitant une validation, l'attaquant a utilisé les identifiants dérobés de plusieurs développeurs.
Le 21 octobre, la version compromise de LiteLLM 1.107.0 est apparue sur les canaux de distribution officiels PyPI et Docker.
Le plus préoccupant : les images Docker compromises portaient une signature valide générée par l'ancienne clé du projet.
Cette signature confirmait que l'image était passée par le mécanisme de publication de confiance... sauf que ce mécanisme était désormais sous le contrôle de l'attaquant.
Que s'est-il passé après l'installation ?
Le paquet Python infecté contenait des fichiers spéciaux conçus pour exécuter du code malveillant lors de l'initialisation standard de Python.
L'application n'avait même pas besoin d'interagir directement avec LiteLLM.
Il suffisait de lancer Python dans l'environnement touché.
Le programme malveillant récoltait les secrets accessibles : clés API de réseaux de neurones, identifiants cloud, clés SSH, variables d'environnement et informations issues des configurations.
Pour une passerelle IA, le risque est particulièrement élevé.
Étant donné qu'elle gère les requêtes de plusieurs fournisseurs de modèles, un grand nombre de clés précieuses se trouvent regroupées au sein d'un même système.
Les versions malveillantes ont été retirées le jour même. Néanmoins, la suppression d'un paquet infecté ne permet pas de récupérer des secrets d'ores et déjà volés.
Pourquoi la signature numérique n'a-t-elle pas sauvé la situation ?
C'est là que réside la principale leçon à retenir.
Une signature numérique répond à la question : « Qui a signé ce fichier ? »
Mais elle ne répond pas toujours à une autre : « Le processus de création du fichier était-il sécurisé ? »
Si un attaquant prend le contrôle de la chaîne de compilation ou de la clé de signature, un produit malveillant peut tout à fait être accompagné d'une signature en apparence irréprochable.
À la suite de cet incident, LiteLLM a remplacé sa clé de signature de conteneurs cosign et a commencé à publier ses images avec une nouvelle clé.
Cela signifiait que les administrateurs devaient non seulement mettre à jour le programme, mais aussi réévaluer quelles signatures ils choisissaient de dôter de leur confiance.
Novembre a ajouté un nouveau chapitre inquiétant
Le 2 novembre, des informations ont été publiées concernant la faille CVE-2026-105769, une vulnérabilité critique affectant l'outil de création de conteneurs kaniko.
Dans certaines conditions, une adresse de registre de conteneurs contrefaite pouvait inciter une version vulnérable de kaniko à envoyer un jeton cloud Azure vers le serveur de l'attaquant.
Une simple référence à une image externe dans le fichier Dockerfile suffisait, sans qu'il soit nécessaire d'exécuter une commande malveillante à l'intérieur du conteneur en cours de construction.
Cette défaillance touche kaniko jusqu'à la version 1.25.20, dès lors qu'une identité Azure est accessible et que les conditions de compilation requises sont réunies.
Bien qu'il s'agisse d'un incident distinct et non lié formellement à l'attaque initiale contre LiteLLM,
ces deux affaires illustrent un problème fondamental : l'infrastructure qui crée et distribue les logiciels devient elle-même une cible privilégiée.
Que doit faire le propriétaire d'un serveur ?
Il ne suffit pas de auditer Linux et les ports ouverts.
- Ne jamais stocker de clés administratives à longue durée de vie dans les dépôts de code. Si un secret est compromis, il doit être révoqué immédiatement, et pas seulement supprimé du fichier.
- Restreindre les privilèges des jetons GitHub et des systèmes de compilation automatisée.
- Figer les versions des dépendances et les empreintes (digest) des conteneurs. Ne vous fiez pas aveuglément au tag
latest. - Vérifier l'origine de la compilation et pas seulement la présence d'une signature numérique.
- Éviter d'accorder aux conteneurs de build un accès global à tous les secrets du cloud.
- En cas de compromission avérée, réinstaller l'environnement à partir d'une source de confiance et renouveler toutes les clés potentiellement exposées.
Pour les serveurs VPN, cette rigueur est primordiale : des clés et des configurations dérobées peuvent transformer un tunnel sécurisé en vecteur de vulnérabilité.
Quant aux services d'intelligence artificielle, les répercussions peuvent impacter simultanément plusieurs plateformes externes.
Qui contrôle réellement votre serveur ?
Vous pouvez installer la dernière version de Linux, configurer minutieusement votre pare-feu, activer l'authentification multifacteur et vous prémunir contre les DDoS.
Mais si votre système accepte automatiquement une mise à jour malveillante, l'attaquant n'aura nul besoin de contourner ces remparts par des méthodes conventionnelles.
Il entrera par la porte que vous aurez vous-même grande ouverte pour accueillir un logiciel de confiance.
La véritable sécurité ne commence pas par se demander où est hébergé le serveur, mais par savoir à qui et pourquoi ce serveur fait confiance.
C'est précisément ce que l'attaque d'octobre contre LiteLLM a mis en lumière de manière éclatante.
Pont de Verre | 6 novembre 2026
Sources :
- LiteLLM, The attack chain behind the v1.107.0 LiteLLM release, 23.10.2026 : https://docs.litellm.ai/blog/security-incident-oct-21-2026-attack-chain
- LiteLLM, Contained: Oct 21, 2026 LiteLLM release v1.107.0 Compromised : https://docs.litellm.ai/blog/security-incident-oct-21-2026
- Microsoft Security Research, Inside the LiteLLM 1.107.0 supply chain compromise, 23.10.2026 : https://www.microsoft.com/en-us/security/blog/2026/10/23/inside-the-litellm-1-107-0-supply-chain-compromise-credential-theft-through-python-startup-hooks/
- GitHub Security Advisory, CVE-2026-105769 : https://github.com/advisories/GHSA-5q7h-w9jf-cx97