Analyse : attaque supply chain LiteLLM. Ce qui s'est passé, comment nous avons réagi

Le 23 mars 2026, un composant logiciel utilisé par des milliers d’entreprises dans le monde, LiteLLM, a été compromis. Pendant quelques heures, toute organisation qui installait ce composant recevait, à son insu, un code malveillant capable de voler ses mots de passe, ses clés d’accès aux services cloud et ses identifiants de bases de données.

Ce type d’attaque, une supply chain attack, ne cible pas directement votre infrastructure. Elle empoisonne un outil que vous utilisez déjà, ou qu’un outil que vous utilisez installe sans que vous le sachiez.

Chez Rosecape, nous utilisions une version stable et vérifiée de LiteLLM dans notre infrastructure interne. Nous n’avons pas été impactés, mais cet incident nous a poussés à agir rapidement et à tirer des leçons concrètes. Voici ce qui s’est passé, comment nous avons réagi et ce que cet incident devrait changer dans la façon dont les PME abordent la sécurité de leurs outils IA.

Ce qui s’est passé

LiteLLM est un logiciel open source qui permet de se connecter à plusieurs fournisseurs d’intelligence artificielle via une interface unique. C’est un outil populaire, largement adopté dans l’écosystème IA.

Le 23 mars, un attaquant a publié deux versions malveillantes du composant sur PyPI, le registre public de paquets Python. Le code injecté faisait deux choses :

1. Collecte silencieuse de toutes les données sensibles accessibles sur la machine : mots de passe, identifiants de services cloud, clés d’accès aux serveurs, historique de commandes.
2. Exfiltration de ces données vers un serveur contrôlé par l’attaquant.

Le tout se déclenchait simplement en installant le composant, sans aucun signe visible.

La compromission a été rendue publique le 24 mars. Les versions malveillantes ont été retirées dans la foulée, mais pour les organisations qui les avaient installées durant cette fenêtre de près de 24 heures, le mal était fait.

Un outil de sécurité comme point d’entrée

Ce qui rend cette attaque particulièrement marquante, c’est son origine.

L’infrastructure LiteLLM utilisait Trivy, un outil de sécurité reconnu dans l’industrie, conçu justement pour détecter les vulnérabilités dans les composants logiciels. Le problème : Trivy lui-même avait été compromis quelques jours plus tôt.

Le 19 mars, un groupe d’attaquants connu sous le nom de TeamPCP a réussi à injecter du code malveillant dans Trivy en exploitant une faille dans les mécanismes d’automatisation du projet. Pendant environ trois heures, toute organisation qui utilisait Trivy dans ses processus automatisés voyait ses identifiants et secrets d’accès récoltés silencieusement.

C’est exactement ce qui est arrivé à LiteLLM. Leur processus de validation automatisé utilisait Trivy pour scanner leurs composants. Quand le Trivy compromis s’est exécuté dans leur pipeline, il a récolté les identifiants de publication du paquet LiteLLM. Avec ces identifiants en main, les attaquants ont pu publier les versions malveillantes de LiteLLM directement sur le registre public.

L’ironie est frappante : l’outil censé protéger la chaîne d’approvisionnement est devenu le vecteur d’attaque.

Et LiteLLM n’est pas la seule victime. Le même groupe a utilisé les accès volés via Trivy pour compromettre des packages sur npm (l’écosystème JavaScript), des extensions Visual Studio Code et des images sur Docker Hub. C’est une campagne coordonnée qui a touché plusieurs écosystèmes en parallèle.

Comment nous avons réagi

Le 24 mars, quelques heures après l’annonce publique de la compromission, nous avions déjà complété notre investigation et sécurisé l’ensemble de nos environnements.

Notre constat : Rosecape n’a pas été impacté. Notre architecture de déploiement fige les versions de chaque composant au moment de la mise en production. Le composant compromis n’a jamais été installé dans nos systèmes.

Malgré ce constat, nous avons appliqué le principe de précaution :

• Arrêt immédiat de tous les services internes liés à LiteLLM, sans impact sur les données ou les environnements clients
• Audit complet de chaque environnement pour confirmer qu’aucune version compromise n’avait été installée
• Gel des mises à jour de LiteLLM jusqu’à la publication d’un audit de sécurité indépendant
• Rotation préventive de nos identifiants internes par mesure de bonne pratique, bien qu’aucune exposition n’ait été détectée
• Contournement architectural : nous avons modifié nos systèmes pour communiquer directement avec nos fournisseurs IA, éliminant la dépendance à LiteLLM sans interrompre les fonctionnalités qui en dépendaient. Le contournement est déjà en production et nous évaluons nos options définitives pour consolider cette transition.

Ce temps de réaction, quelques heures entre l’annonce et la sécurisation complète, n’est pas le fruit du hasard. C’est le résultat d’une visibilité complète sur notre infrastructure : nous savions exactement où ce composant était déployé, sous quelle version et dans quel contexte.

Pourquoi cette attaque est un signal d’alarme pour les PME

Cette attaque n’exploitait pas une faille technique complexe. Elle exploitait la confiance implicite que nous accordons tous à nos outils logiciels. Et dans ce cas, même la confiance envers un outil de sécurité s’est retournée contre ses utilisateurs.

C’est un problème structurel. La majorité des applications modernes, y compris les outils d’IA, reposent sur des centaines de composants, chacun maintenu par une communauté open source de développeurs souvent bénévoles. Compromettre un seul compte suffit à atteindre des milliers d’organisations en aval.

Pour les PME, le risque est amplifié par trois tendances actuelles.

Le « vibe coding » : quand l’IA écrit votre code sans supervision

Le vibe coding, cette pratique où l’on laisse un assistant IA générer du code avec un minimum de supervision, est en pleine expansion. C’est rapide, productif et souvent impressionnant.

Mais imaginez le scénario suivant : un employé demande à un assistant IA de connecter une application à plusieurs fournisseurs d’intelligence artificielle. L’assistant suggère d’installer LiteLLM, un choix parfaitement logique et répandu. L’employé accepte en un clic. Si ça s’était passé le 23 mars 2026, tous les identifiants de cette machine étaient compromis.

Le problème n’est pas l’IA qui fait la suggestion. Le problème, c’est l’absence de cadre autour de cette pratique. Quand on travaille à la vitesse de la conversation avec un assistant IA, personne ne s’arrête pour vérifier la fiabilité d’un composant.

L’analyse de données d’entreprise sur des machines non protégées

L’autre angle mort concerne les équipes qui utilisent des outils IA pour analyser les données de l’entreprise, directement sur leur poste de travail, sans environnement dédié.

Le problème : ces mêmes postes de travail contiennent souvent les accès à tous les systèmes de l’entreprise. Mots de passe enregistrés, accès aux serveurs, connexions aux services cloud, identifiants de bases de données.

Quand un composant compromis s’exécute sur ce type de machine, il a accès à tout. Ce n’est pas un risque théorique. C’est exactement ce que le code malveillant de LiteLLM faisait : récolter tout ce qui était accessible.

Le réflexe naturel d’un employé est de travailler là où ses outils sont déjà configurés. Mais « là où c’est pratique » est rarement « là où c’est sécuritaire ».

La dépendance invisible aux composants tiers

LiteLLM n’est pas un produit que la plupart des dirigeants de PME connaissent. Trivy non plus. Ce sont des composants techniques, des couches intermédiaires. Et pourtant, la compromission de l’un a mené à la compromission de l’autre, qui aurait pu exposer les données les plus sensibles de n’importe quelle organisation en aval.

C’est la nature des attaques supply chain : elles frappent dans les angles morts. Pas dans les systèmes que vous surveillez, mais dans les outils que vos outils utilisent. Et parfois, dans les outils de sécurité eux-mêmes.

Ce que les PME devraient faire maintenant

1. Isoler les environnements de développement et d’analyse

Ne faites jamais d’analyse de données internes ou de développement IA sur une machine qui a accès à vos identifiants de production. Utilisez des environnements isolés — conteneurs, machines virtuelles, espaces de travail dédiés — où les secrets de production ne sont tout simplement pas accessibles.

2. Épingler et vérifier les dépendances

Ne faites pas confiance aux « dernières versions ». Épinglez vos dépendances à des versions spécifiques et vérifiées. Pour les images Docker, utilisez des identifiants SHA plutôt que des tags mutables comme latest ou stable.

3. Encadrer l’utilisation des assistants IA pour le code

Le vibe coding n’est pas le problème — l’absence de politique de sécurité autour de cette pratique l’est. Établissez des règles claires : quels paquets peuvent être installés, dans quels environnements, et avec quelle supervision.

4. Inventorier vos dépendances critiques

Savez-vous quels composants open source font fonctionner vos outils IA ? Si la réponse est non, c’est le moment de faire l’inventaire. Vous ne pouvez pas protéger ce que vous ne connaissez pas.

5. Planifier votre réponse avant l’incident

Notre temps de réaction se mesure en heures parce que nous avions la visibilité sur notre propre infrastructure. Nous savions exactement où LiteLLM était déployé, sous quelle version et dans quel contexte. Sans cette visibilité, une organisation peut passer des jours — voire des semaines — à simplement comprendre si elle est touchée.

L’intelligence productive commence par la maîtrise

Cet incident illustre une réalité que nous répétons souvent : la technologie n’a de valeur que si elle est maîtrisée. L’IA est un levier extraordinaire pour les PME, mais seulement si les fondations sont solides.

Chez Rosecape, notre approche repose sur des principes qui nous ont protégés dans cet incident : des composants contrôlés, des environnements isolés, une infrastructure gérée et hébergée au Canada, et une visibilité complète sur chaque élément de notre chaîne de données.

Si vous souhaitez évaluer la posture de sécurité de votre infrastructure de données et d’IA, parlons-en.