De Shai-Hulud à LiteLLM : les auteurs d’attaques de la chaîne d’approvisionnement s’en prennent à vos agents

Attaquants de la chaîne d’approvisionnement_863x300

L’atteinte à la chaîne d’approvisionnement de LiteLLM en date du 24 mars 2026 n’est pas un événement isolé. C’est le volet le plus récent, et sans doute le plus menaçant, d’un répertoire d’attaques en mutation que JFrog Security Research analyse depuis des années. L’objectif a évolué : les cibles ne sont plus les développeurs, mais les agents d’intelligence artificielle dont ils dépendent pour développer des applications.
La cible a toujours été le développeur
Une attaque de la chaîne d’approvisionnement obéit à un principe simple : identifier un composant open source de confiance, le corrompre et laisser l’écosystème faire le travail de diffusion. Shai-Hulud, dont la découverte a été signalée en septembre 2025 et qui a fait l’objet d’une analyse approfondie par l’équipe JFrog Security Research, en constituait une parfaite illustration. S’appuyant sur un ver auto-réplicatif inclus dans des paquets npm, il était conçu pour dérober les jetons d’accès des développeurs et réinfecter automatiquement d’autres packages gérés par ces derniers. Comme il s’est propagé de manière exponentielle sans aucune intervention directe des attaquants, il est considéré comme l’une des pires attaques de la chaîne logistique JavaScript de l’histoire.

Afin d’aider les entreprises à se prémunir contre ce type de risque, JFrog Curation propose un mécanisme de filtrage automatisé qui neutralise les packages open source malveillants et vulnérables avant leur arrivée dans les environnements de développement.
Le SDLC se transforme, et la surface d’attaque fait de mêmeAuteurs d’attaques de la chaîne d’approvisionnement agentique – image3Auteurs d’attaques de la chaîne d’approvisionnement agentique – image1
Outre les développeurs eux-mêmes, les cybercriminels exploitent également les failles présentes dans le code produit par l’intelligence artificielle. Les développeurs ne comptent plus seulement sur leurs talents de codeurs, mais coordonnent à la place plusieurs agents d’intelligence artificielle en même temps en vue de coder, tester, rechercher et déployer. Le cycle de vie du développement s’est transformé, évoluant d’un processus linéaire et humain vers un pipeline distribué géré par de multiples agents.

Avant le code généré par l’IA :

Après le code généré par l’IA :

Chaque développeur peut désormais exécuter plusieurs agents en parallèle, chacun s’interfaçant avec des packages d’IA, des serveurs MCP, des modèles et des compétences, ce qui entraîne une expansion rapide de la surface d’attaque.

La clé pour appréhender cette nouvelle surface d’attaque réside dans la compréhension du fonctionnement d’un agent. Un agent IA ne se résume pas à un modèle ; il s’agit d’une composition de ressources d’IA :

Le LLM dans son essence
Les règles et la mémoire qui façonnent son comportement
Les compétences d’agent qu’il peut exécuter
Les serveurs MCP qui le connectent aux systèmes externes et aux données
Auteurs d’attaques de la chaîne d’approvisionnement agentique – image2
Chacun de ces composants représente un vecteur d’attaque/de risque potentiel.

Composition d’un agent IA

Les agents sont désormais la cible
Alors que les mesures de sécurité sur la chaîne logistique ont complexifié la corruption des environnements de développement, les pirates ont changé de stratégie. S’il est impossible d’atteindre le développeur, autant cibler ses outils.

Septembre 2025 postmark-mcp : le premier serveur MCP malveillant dans la nature.

Un acteur malveillant a cloné le dépôt légitime Postmark MCP et a publié un package npm quasi identique. Pendant quinze versions, il a fonctionné à la perfection et a été plébiscité par des développeurs dans des centaines de workflows. Puis la version 1.0.16 a introduit une simple ligne de code, une copie cachée (BCC),  qui transférait discrètement chaque e-mail envoyé via le serveur MCP vers un domaine contrôlé par un attaquant. Mots de passe réinitialisés, factures et mémos internes ont fait  l’objet d’une exfiltration silencieuse au cœur même des processus d’agents d’intelligence artificielle qui avaient aveuglément fait confiance au connecteur.

Ce qui l’a rendu particulièrement dangereux, c’est que les serveurs MCP fonctionnent avec une grande confiance et de larges privilèges au cœur des chaînes d’outils des agents. Loin de se limiter à la contamination d’une unique base de code,  un serveur MCP compromis s’établit comme un plan de contrôle en amont pérenne, en mesure de pirater un workflow complet piloté par l’intelligence artificielle et tous ses environnements connectés.

Si l’incident postmark-mcp constituait un avertissement, la brèche LiteLLM représente quant à elle une escalade majeure.
L’attaque LiteLLM : un nouveau niveau de sophistication
Agissant comme une passerelle universelle vers plus de 100 API de grands modèles de langage — parmi lesquelles OpenAI, Anthropic, AWS Bedrock et Google VertexAI —, LiteLLM s’impose comme l’un des packages les plus indispensables de l’écosystème de l’intelligence artificielle. Le package enregistre environ 3,4 millions de téléchargements par jour et est présent dans 36 % des environnements cloud. Il s’agit par ailleurs d’une dépendance transitive courante au sein des extensions MCP et des environnements de travail pour agents intelligents, ce qui motive directement son choix comme cible. Consultez l’analyse technique complète de l’attaque par l’équipe de recherche en sécurité de JFrog pour plus de détails.

Cette cyberattaque a été orchestrée par TeamPCP, le collectif responsable des intrusions récentes visant le scanner Trivy d’Aqua Security et l’action GitHub KICS de Checkmarx. Loin d’être fortuite, cette attaque relevait d’une campagne orchestrée et cumulative.
Comment cela s’est produit
Le processus d’intégration et de déploiement continus (CI/CD) de LiteLLM intégrait Trivy au moment du build, sans qu’aucune version spécifique n’ait été figée. Le 19 mars, TeamPCP avait déjà compromis l’action GitHub de Trivy. Au moment du build de LiteLLM, l’action Trivy piégée s’est emparée du jeton de publication PyPI du projet directement sur le runner GitHub Actions pour l’envoyer à l’extérieur. Armés de ces identifiants, les pirates ont diffusé, le 24 mars au matin, les versions 1.82.7 et 1.82.8 de litellm ; celles-ci intégraient des charges offensives  contournant totalement le processus de release classique de l’outil.
Ce que le logiciel malveillant a fait
Une fois déclenchée, la charge utile a exécuté une attaque en trois étapes :

Collecte d’identifiants tels que les clés SSH, les jetons cloud AWS, GCP et Azure, les secrets Kubernetes, les portefeuilles crypto et les fichiers .env .
Tentative de mouvement latéral à travers les clusters Kubernetes en déployant des pods privilégiés sur chaque nœud.
Installation d’une porte dérobée systemd persistante qui interroge une infrastructure contrôlée par l’attaquant pour obtenir des fichiers binaires supplémentaires. Toutes les données collectées ont été chiffrées et exfiltrées vers models.litellm.cloud — un domaine usurpant l’identité de l’infrastructure LiteLLM légitime, enregistré le jour même de l’attaque

La version 1.82.8 s’est révélée particulièrement agressive, puisqu’elle exploitait le mécanisme de fichiers .pth de Python, lequel s’exécute à chaque démarrage de l’interpréteur Python, que LiteLLM soit explicitement importé ou non. La charge utile était encodée deux fois en base64 pour échapper à l’analyse statique.
Comment cela a été découvert  – À l’intérieur d’un agent
L’incident a été détecté initialement au moment où l’extension a été appelée sous forme de dépendance transitive par un module MCP tournant dans l’environnement de Cursor. L’ordinateur d’un chercheur s’est figé en raison d’une saturation de la mémoire vive, un dommage collatéral lié à un bug de type fork-bomb propre au logiciel malveillant. Le package corrompu s’était infiltré dans l’espace d’exécution d’un agent intelligent sans qu’aucune intervention humaine consciente n’en ait acté l’installation préalable.
L’impact organisationnel
Étant donné que LiteLLM s’intercale directement entre les applications et différents prestataires d’IA, l’outil centralise les clés d’API, les variables d’environnement ainsi que les informations de configuration confidentielles de l’ensemble de l’infrastructure IA de l’entreprise. Un simple poste infecté compromet les clés d’accès de tous les services d’IA exploités par une entreprise, peu importe l’environnement d’exécution de LiteLLM — qu’il s’agisse des postes de travail, des pipelines CI/CD, des serveurs de staging ou de la production. Les versions malveillantes sont restées en ligne sur PyPI pendant environ trois heures. Compte tenu du volume de téléchargement du package, l’exposition potentielle durant cette fenêtre était considérable.
Le schéma est clair

Attaque
Vecteur
Cible

Shai-Hulud (npm)
Ver auto-réplicatif dans les packages open source
Environnements de développement

postmark-mcp (npm)
Serveur MCP malveillant
Workflows d’agents IA

LiteLLM (PyPI)
Package d’infrastructure d’IA empoisonné via un outil CI compromis
Runtimes d’agent + CI/CD

 

Non seulement la surface d’attaque s’est élargie,   mais elle se trouve désormais multipliée par la quantité d’agents que chaque développeur déploie. Une seule dépendance d’IA compromise peut se propager en cascade dans tous les environnements où les agents fonctionnent simultanément.
Le problème de la passerelle d’IA open source
Le rôle de LiteLLM dans l’écosystème mérite d’être examiné de près. À la base, il s’agit d’une passerelle d’IA open source utilisant une unique couche de routage interposée entre vos applications et chaque API de LLM que vous utilisez. Cette position architecturale est puissante. C’est précisément cette caractéristique qui en fait une cible de choix aux conséquences dévastatrices pour les attaquants.

Faire transiter tout votre trafic lié à l’intelligence artificielle par un seul et même package open source revient à placer une confiance aveugle dans son intégrité, dans la rigueur de ses mainteneurs en matière de sécurité ainsi que dans la chaîne de publication qui l’accompagne. L’affaire du piratage de LiteLLM a mis en lumière la fragilité extrême d’un tel niveau de confiance. Il a suffi d’une simple dépendance non verrouillée dans un pipeline CI pour céder aux assaillants le contrôle de l’infrastructure IA globale d’une structure, compromettant au passage  chaque clé d’API, chaque jeton cloud et chaque information sensible de l’environnement.

Bien entendu, il n’est pas question de bouder la puissance offerte par les passerelles d’intelligence artificielle. En revanche, nous défendons avec conviction l’importance de les édifier sur des bases de sécurité solides. Une passerelle d’intelligence artificielle positionnée au cœur de votre chaîne logistique d’agents requiert une gouvernance dotée de sécurités de niveau professionnel,  plutôt qu’une simple récupération sur un dépôt public en croisant les doigts.
Construire une chaîne d’approvisionnement agentique de confiance
Il ne s’agit pas pour autant de ralentir ou de proscrire le déploiement de l’intelligence artificielle. Il s’agit d’arrêter de faire une confiance aveugle à la couche d’IA et de commencer à la régir avec la même rigueur que celle appliquée au reste de la chaîne d’approvisionnement logicielle.

C’est précisément pour cette raison que nous avons lancé  JFrog AI Catalog et son AI Gateway, conçu dès le départ autour du principe selon lequel la fiabilité de vos agents dépend entièrement de ce qu’ils ingèrent, produisent et diffusent.
La passerelle d’IA : miser sur la sécurité native
À la différence d’une passerelle open source qui se contente de router le trafic sans garantie, la solution JFrog AI Gateway est pensée pour servir de couche de liaison sécurisée et conforme aux règles établies. La solution centralise l’ensemble  des flux de consommation d’IA, des serveurs MCP et des compétences d’agents  via un point de contrôle unique, unifiant ainsi la gouvernance de toute votre empreinte d’intelligence artificielle. La plateforme veille par ailleurs à ce que chaque demande soit authentifiée et à ce que chaque ressource en aval fasse l’objet d’un contrôle approfondi avant toute autorisation.

Voici la nuance architecturale essentielle : la JFrog AI Gateway ne sert pas seulement de proxy pour le trafic, elle garantit la sécurité dès le point de connexion, en amont de toute interaction entre un agent et un modèle ou un serveur MCP non certifié.
Le registre MCP JFrog : fini la confiance aveugle
Le registre JFrog MCP Registry a été conçu pour faire face directement à ce type d’attaque bien précis, illustré par postmark-mcp et LiteLLM. Il considère les serveurs MCP comme  des composants régis de la même façon que JFrog l’a toujours fait pour sécuriser  les packages logiciels, en intégrant directement des fonctions d’analyse, de contrôle des règles et de versionnage.

Concrètement, le MCP Registry propose les fonctionnalités clés suivantes :
Sécurité native dès la conception
Bloquer de manière proactive les serveurs MCP malveillants ou non conformes avant qu’ils ne soient téléchargés ou exécutés par des agents, plutôt que de les détecter après une compromission.
Gouvernance centralisée
Les développeurs accèdent à un registre de serveurs MCP pré-approuvés directement depuis leurs IDE (Cursor, Claude Code, VS Code), sans avoir besoin de les récupérer depuis des registres publics.
Application de politiques de niveau entreprise
Remplacement de la « confiance aveugle » par des autorisations granulaires au niveau du projet qui contrôlent précisément les serveurs MCP auxquels les agents sont autorisés à se connecter.
Une passerelle MCP locale
Un proxy léger qui gère de manière transparente l’authentification et les contrôles d’autorisation sur la machine du développeur, garantissant que les agents de codage ne se connectent qu’à des serveurs pré-vérifiés.
La réussite de l’attaque visant postmark-mcp découle du fait qu’un développeur a importé un serveur MCP issu d’un registre public sans remettre en question sa fiabilité. Le succès de l’attaque contre LiteLLM s’explique par le fait qu’un processus de build a accordé sa confiance aveugle à un composant open source non verrouillé. Le registre JFrog MCP Registry est élaboré pour empêcher que de tels scénarios ne surviennent à l’insu du développeur : chaque serveur MCP y est traité comme un composant contrôlé, et tout élément non validé est stoppé net à l’entrée.

Le registre JFrog MCP Registry est élaboré pour empêcher que des attaques comparables à postmark-mcp ou LiteLLM ne surviennent à l’insu des équipes de développement et d’exploitation : chaque serveur MCP y est traité comme un composant contrôlé, et tout élément non validé est stoppé net à l’entrée.
Un système unique d’enregistrement pour l’ensemble de la chaîne d’approvisionnement agentique
L’ambition plus vaste est d’établir un référentiel unique supervisant l’ensemble des éléments consommés et produits par les agents (modèles, serveurs MCP, compétences d’agents, code généré par l’intelligence artificielle et objets assemblés), centralisant ainsi la gestion sous les mêmes exigences de sécurité et de conformité que l’ensemble de la chaîne logistique logicielle.

C’est ce que JFrog appelle une chaîne d’approvisionnement agentique de confiance. La solution transpose au domaine de l’intelligence artificielle et à ses nouveaux types de ressources les principes de sécurité éprouvés depuis des décennies pour les chaînes logistiques de logiciels, incluant l’immutabilité, la traçabilité, le respect des règles et l’analyse continue. Elle est validée par des partenariats avec des acteurs comme NVIDIA, dont l’environnement d’exécution OpenShell s’appuie sur la plateforme JFrog en tant que point de terminaison administré pour diffuser des compétences d’agents vérifiées à grande échelle.
Comment JFrog aide à protéger votre chaîne d’approvisionnement agentique
En devenant partenaire de JFrog, vous pouvez commencer à protéger votre organisation contre les dernières attaques de la chaîne d’approvisionnement en suivant les étapes suivantes :

Auditez vos chaînes de dépendances d’IA, y compris les dépendances transitives récupérées par les agents et les plugins MCP
Assurez-vous de figer les versions car l’attaque LiteLLM a exploité des dépendances non figées à plusieurs points de la chaîne
Arrêtez de voir dans les passerelles d’intelligence artificielle open source des environnements de confiance par défaut, et privilégiez un routage des flux via des passerelles professionnelles et sécurisées par des règles strictes.
Gouvernez vos serveurs MCP — utilisez JFrog MCP Registry pour veiller à ce que les agents ne se connectent qu’à des serveurs vérifiés et approuvés
Effectuez une rotation stricte des informations d’identification après toute suspicion de compromission en partant du principe que l’ensemble du système est compromis, et pas seulement en supprimant le package
Créez un catalogue d’IA de confiance – utilisez JFrog AI Catalog comme système d’enregistrement unique pour les modèles, les MCP, les compétences et les packages d’IA

Points clés à retenir
Le SDLC a changé. Les développeurs ne sont plus les seuls acteurs du pipeline, ils sont désormais les orchestrateurs de flottes d’agents, chacun consommant des ressources d’IA à la vitesse de la machine. Les cybercriminels emboîtent le pas aux équipes dans tous les nouveaux environnements qu’elles adoptent, sans épargner leurs processus pilotés par des agents.

L’incident LiteLLM a agi comme une véritable sonnette d’alarme. L’événement a mis en lumière qu’une passerelle d’intelligence artificielle open source positionnée au centre de votre architecture n’a rien de neutre et constitue au contraire  une cible de premier choix. Tout l’enjeu est désormais de déterminer si votre architecture de confiance est taillée pour faire face à cette nouvelle donne.

Chez JFrog, notre conviction est que la sécurité doit faire partie intégrante de la plateforme dès l’origine, plutôt que d’être présumée ou greffée a posteriori. Concrètement, il s’agit de sélectionner les packages open source, d’encadrer les modèles d’IA, de sécuriser les serveurs MCP au moyen d’un registre doté de contrôles de conformité préexécutifs et de faire transiter l’ensemble des flux d’IA par une passerelle axée sur la sécurité.

En effet, dans un univers dopé à l’intelligence artificielle, la rapidité ne constitue un atout qu’à la condition absolue de reposer sur des bases sûres.

Réservez une démo avec l’un de nos experts pour assister à une démonstration en direct des solutions JFrog. Vous pouvez également en savoir plus sur JFrog AI Catalog, le JFrog MCP Registry et JFrog Curation.