Attaques de la chaîne d'approvisionnement IA : la chaîne d'approvisionnement est la surface

Le 19 mars 2026, un groupe malveillant nommé TeamPCP a force-pushé 76 des 77 tags de version du dépôt GitHub trivy-action d’Aqua Security. Trivy est le scanner de vulnérabilités open source le plus largement déployé du secteur. Les nouveaux tags pointaient vers des commits malveillants contenant un voleur d’identifiants. Puisque la plupart des pipelines CI/CD référencent les Actions GitHub par des tags de version mutables plutôt que par des SHA de commit épinglés, toutes les organisations exécutant Trivy dans leur pipeline de build ont commencé à exécuter immédiatement le code malveillant. Les scans semblaient toujours réussir. Le scanner rapportait toujours des vulnérabilités. Il récoltait aussi silencieusement tous les secrets de l’environnement du runner.¹

Les attaques sur la chaîne d’approvisionnement exploitent la composition d’opérations autorisées pour produire un comportement non autorisé. Après avoir compromis Trivy via le détournement de tags d’Actions GitHub, les attaquants ont utilisé des identifiants CI volés pour installer une porte dérobée dans LiteLLM sur PyPI, atteignant 46 996 installations en 46 minutes. Chaque composant opérait dans les limites des permissions qui lui étaient accordées. La défense structurelle consiste à épingler les dépendances à des références immuables et à traiter l’installation de paquets comme une exécution de code.

Cinq jours plus tard, le 24 mars, TeamPCP a utilisé un token de publication PyPI volé depuis l’un de ces environnements CI pour publier deux versions de LiteLLM avec des portes dérobées, une bibliothèque de proxy IA populaire présente dans 36 % des environnements cloud.² La version 1.82.8 incluait un fichier .pth qui s’exécute automatiquement au démarrage de tout Python, avant tout import, avant tout sandbox au niveau applicatif. La charge utile a balayé les clés SSH, les identifiants cloud, les mots de passe de base de données, les portefeuilles de cryptomonnaies et les secrets CI/CD, les a chiffrés avec une clé publique RSA codée en dur et a exfiltré l’archive vers un domaine contrôlé par l’attaquant, enregistré la veille.³

PyPI a mis en quarantaine les deux versions après 46 minutes. Dans ce laps de temps, 46 996 installations ont eu lieu.⁴ Le mainteneur de LiteLLM a supprimé son compte GitHub, a changé toutes les clés et a engagé Mandiant.⁵

Le scanner de sécurité a scanné. Le pipeline de build a buildé. Le gestionnaire de paquets a installé. Chaque composant a fait exactement ce qu’on lui faisait confiance pour faire.

TL;DR

• La chaîne : TeamPCP a compromis Trivy (scanner de sécurité) le 19 mars via le détournement de tags d’Actions GitHub, puis a compromis LiteLLM (proxy IA) le 24 mars en utilisant un token PyPI volé depuis un environnement CI infecté par Trivy. 46 996 téléchargements en 46 minutes.⁴
• La technique : la version 1.82.8 abuse du mécanisme .pth de Python pour exécuter un voleur d’identifiants à chaque invocation de python3 sur le système infecté, sans importer LiteLLM.³
• Le rayon d’impact : 2 337 paquets PyPI dépendent de LiteLLM. 88 % avaient des spécifications de version qui autorisaient les versions compromises. Impact en aval confirmé sur Google ADK, Stanford DSPy, MLflow, Guardrails AI et Cisco AI Defense SDK.⁴
• La campagne : TeamPCP a frappé cinq écosystèmes en une semaine : Actions GitHub, Docker Hub, npm (CanisterWorm, 28+ paquets), Open VSX (Checkmarx KICS) et PyPI (LiteLLM).⁶
• La leçon structurelle : chaque maillon de la chaîne opérait dans le cadre de la portée qui lui était accordée. La composition de ces opérations autorisées a produit un comportement non autorisé. Le schéma reflète l’écart de composition qui permet l’exfiltration silencieuse au niveau de l’agent et Clinejection au niveau CI/CD. Les attaques sur la chaîne d’approvisionnement sont des attaques de composition.
• Ce que vous pouvez faire : épinglez les dépendances à des références immuables. Isolez les identifiants de publication des runners CI. Surveillez les requêtes réseau sortantes au niveau du système d’exploitation. Traitez pip install comme une exécution de code, parce que c’en est une.

Un scanner de sécurité entre dans votre pipeline de build

L’attaque a commencé par une mauvaise configuration dans l’environnement d’Actions GitHub de Trivy fin février 2026. Un attaquant a exploité un workflow pull_request_target vulnérable pour exfiltrer le token d’accès personnel aqua-bot d’Aqua Security. Aqua a changé certains identifiants le 1er mars, mais en a oublié d’autres. TeamPCP a conservé des tokens valides.¹

Le 19 mars, ils ont utilisé ces tokens pour force-pusher 76 des 77 tags de version du dépôt trivy-action et l’ensemble des 7 tags de setup-trivy, redirigeant chaque référence de tag mutable vers des commits malveillants. Ils ont également déclenché l’automatisation de release pour publier un binaire Trivy malveillant en tant que v0.69.4.¹

La charge utile était un voleur d’identifiants qui vidait la mémoire du processus Runner.Worker, récoltait les clés SSH, les identifiants cloud, les secrets Kubernetes, les configurations Docker, les identifiants Git et les fichiers .env. Il chiffrait le butin avec AES-256 et une clé RSA de 4096 bits, puis exfiltrait l’archive vers des serveurs contrôlés par l’attaquant. Le code malveillant s’exécutait aux côtés de la fonctionnalité légitime de Trivy. Les scans réussissaient. Le scanner rapportait toujours des vulnérabilités. Le voleur tournait en arrière-plan.⁷

Entre le 19 et le 23 mars, les attaquants ont également empoisonné des images Docker Hub sous les tags trivy:0.69.4, trivy:0.69.5, trivy:0.69.6 et trivy:latest. CrowdStrike, Microsoft, Wiz et Palo Alto ont tous publié des analyses techniques en quelques jours.⁷⁸⁹

L’ironie est structurelle : les organisations les plus soucieuses de la sécurité étaient les plus exposées. Si vous exécutiez Trivy en CI parce que vous vous souciez du scan de vulnérabilités, votre pipeline de build était celui qui récoltait les identifiants.

Du scanner au voleur au proxy IA

Le pipeline CI de LiteLLM exécutait Trivy. Plus précisément, ci_cd/security_scans.sh récupérait Trivy via apt depuis le dépôt d’Aqua sans épinglage de version.¹⁰ Pendant la fenêtre de compromission, une exécution CI a récupéré le binaire Trivy empoisonné, qui a récolté le PYPI_PUBLISH_PASSWORD depuis l’environnement des Actions GitHub.

Le 23 mars, l’attaquant a enregistré litellm.cloud. Le 24 mars à 10 h 39 UTC, il a publié litellm==1.82.7 sur PyPI en utilisant les identifiants volés. La version 1.82.8 a suivi à 10 h 52 UTC.⁴

Les deux versions ont utilisé des techniques d’attaque différentes. La version 1.82.7 intégrait la charge utile dans proxy_server.py, qui se déclenche lors de import litellm.proxy. La version 1.82.8 déposait un fichier .pth dans site-packages/, qui se déclenche au démarrage de tout interpréteur Python. Le mécanisme .pth est une fonctionnalité légitime de Python pour la configuration de chemins. Le module site.py de Python exécute automatiquement tout fichier se terminant par .pth qu’il trouve dans site-packages/ pendant l’initialisation de l’interpréteur. La plupart des développeurs Python ne savent pas que cette fonctionnalité existe.³

La charge utile dans les deux versions collectait les variables d’environnement, les clés SSH, les identifiants AWS/GCP/Azure, les configurations Kubernetes, les mots de passe de base de données, les portefeuilles de cryptomonnaies et les secrets CI/CD. Elle chiffrait la collection avec AES-256-CBC en utilisant une clé de session aléatoire, enveloppait la clé de session avec une clé publique RSA de 4096 bits codée en dur et exfiltrait l’archive via HTTPS POST. Seul l’attaquant peut déchiffrer les données volées.³

Un bogue dans le malware 1.82.8 l’a trahi. Le fichier .pth lance un processus Python enfant, qui redéclenche le fichier .pth, créant une bombe de fork exponentielle. Andrej Karpathy a signalé le bogue sur X. Sans la bombe de fork, le voleur aurait tourné silencieusement à chaque invocation Python sur chaque système infecté, potentiellement pendant des semaines avant que quiconque ne le remarque.⁴

PyPI a mis en quarantaine les deux versions à 11 h 25 UTC – 46 minutes d’exposition, 46 996 téléchargements.⁴

Le rayon d’impact

Les développeurs téléchargent LiteLLM environ 3,4 millions de fois par jour. Wiz rapporte qu’il s’exécute dans 36 % des environnements cloud.² La fenêtre d’exposition de 46 minutes a suffi.

FutureSearch a analysé les journaux de téléchargement BigQuery de PyPI et a constaté que pendant la fenêtre d’attaque, pip a récupéré la version 1.82.8 à un taux 6 fois supérieur à celui de toute version sûre. Les téléchargements penchaient fortement vers pip (qui résout vers la dernière version) par opposition à uv (qui utilise des fichiers de verrouillage). Sur les 46 996 téléchargements, 23 142 étaient des installations pip de la v1.82.8, dont chacune exécutait la charge utile pendant l’installation elle-même parce que le fichier .pth se déclenche pendant le propre processus Python de pip.⁴

2 337 paquets sur PyPI dépendent de LiteLLM. 88 % (2 054 paquets) avaient des spécifications de version qui autorisaient l’installation des versions compromises. L’exposition en aval inclut :⁴

Les utilisateurs de LiteLLM Cloud et du proxy Docker n’étaient pas affectés parce que leurs dépendances étaient épinglées dans requirements.txt. La distinction entre « épinglé » et « non épinglé » a fait la différence entre compromis et sûr.⁵

Cinq écosystèmes en une semaine

TeamPCP ne s’est pas arrêté à PyPI. La campagne a frappé cinq écosystèmes de paquets en succession rapide :⁶

Actions GitHub (19 mars) : 76 tags trivy-action et l’ensemble des 7 tags setup-trivy détournés. Binaires Trivy malveillants v0.69.4 à v0.69.6 publiés.

Docker Hub (19-22 mars) : images Trivy malveillantes poussées sous les tags aquasec/trivy:latest et les tags spécifiques de version. Propagées vers mirror.gcr.io.

Open VSX (23 mars) : TeamPCP a compromis l’Action GitHub Checkmarx KICS, détournant 35 tags entre 12 h 58 et 16 h 50 UTC.²

npm (23-24 mars) : CanisterWorm, un ver auto-propagateur, déployé sur plus de 28 paquets npm.

PyPI (24 mars) : les versions 1.82.7 et 1.82.8 de LiteLLM publiées avec des charges utiles de vol d’identifiants.

Chaque compromission d’écosystème utilisait des identifiants récoltés lors de la précédente. La campagne était un graphe orienté d’exploitation de la confiance, où chaque nœud compromis livrait les clés du suivant.

Les attaques sur la chaîne d’approvisionnement sont des attaques de composition

Le schéma structurel de la campagne TeamPCP est le même que celui que j’ai décrit dans le contexte de la sécurité des agents et de l’exfiltration silencieuse : des composants individuellement autorisés se composant en comportement non autorisé.

Trivy avait la permission de s’exécuter en CI. La CI détenait des identifiants de publication par conception. Le gestionnaire de paquets installait des paquets sur commande. Chaque fichier .pth configurait les chemins Python comme prévu. Chaque maillon de la chaîne opérait dans sa portée définie. La composition de ces opérations légitimes a produit une exfiltration d’identifiants à grande échelle.

L’attaque Clinejection a démontré le même schéma au niveau CI/CD : un titre d’issue a injecté du texte adversaire dans le pipeline automatisé de Cline, qui a exécuté un script preinstall npm, qui a empoisonné le cache de build, qui a contaminé les artefacts inter-workflows. Chaque étape détenait sa propre autorisation.¹¹

Le benchmark MCPTox a démontré le même schéma au niveau de l’agent : des instructions malveillantes intégrées dans les descriptions d’outils redirigent les agents pour exfiltrer des identifiants en utilisant des outils légitimes déjà présents sur le serveur. L’agent n’exécute jamais l’outil empoisonné lui-même. Il lit la description empoisonnée et utilise ses propres outils légitimes pour mener l’attaque.¹²

L’exfiltration silencieuse le démontre au niveau de l’exécution : des instructions adversaires dans les métadonnées d’une page web induisent un agent à exfiltrer le contexte d’exécution par une requête HTTP sortante que l’agent a déjà la permission de faire.¹³

La surface d’attaque n’est pas un composant vulnérable unique. La surface d’attaque est la composition de composants de confiance. Sécuriser les maillons individuels ne sécurise pas la chaîne. Trivy seul n’était pas la vulnérabilité. LiteLLM seul n’était pas la vulnérabilité. La relation de confiance entre eux – médiée par des tags de version mutables et des dépendances non épinglées – était la vulnérabilité.

Ce qui aide réellement

Les défenses qui auraient arrêté chaque étape de cette attaque sont ennuyeuses. Ce sont aussi celles que la plupart des organisations sautent.

Épinglez à des références immuables. LiteLLM récupérait Trivy via apt sans épinglage de version. Si security_scans.sh avait été épinglé à une version spécifique ou à un SHA de commit, le binaire v0.69.4 empoisonné n’aurait jamais été exécuté. Les Actions GitHub devraient référencer des SHA de commit, pas des tags mutables. La différence entre uses: aquasecurity/[email protected] (compromis) et uses: aquasecurity/trivy-action@57a97c7 (sûr) est la différence entre perdre vos identifiants de publication ou non.¹

Isolez les identifiants de publication des runners CI. Le PYPI_PUBLISH_PASSWORD était exposé en tant que variable d’environnement dans le runner d’Actions GitHub où Trivy s’exécutait. Si l’équipe avait isolé les identifiants de publication dans un workflow séparé sans dépendances d’actions tierces, la compromission de Trivy n’aurait pas donné accès à PyPI. Les Trusted Publishers (OIDC) de PyPI éliminent entièrement les tokens stockés.⁵

Surveillez les requêtes réseau sortantes. Le voleur d’identifiants exfiltrait les données via HTTPS POST vers models.litellm.cloud, un domaine que les attaquants avaient enregistré 24 heures avant l’attaque. Une surveillance d’egress qui signale les requêtes vers des domaines nouvellement enregistrés aurait attrapé cela. Mon propre système de hooks bloque les requêtes sortantes vers des domaines qui ne sont pas sur une liste d’autorisation, le même schéma qui aurait intercepté cette exfiltration.¹⁴

J’ai appris la même leçon en production à la dure. Un chemin de purge de cache Cloudflare de confiance a déclenché un appel API pleinement autorisé et a quand même produit un mauvais résultat parce que les garde-fous environnants étaient trop permissifs. Cet échec m’a poussé à ajouter des approbations d’actions destructrices et des hooks de préflight autour des opérations à fort impact, pas seulement des listes d’autorisation de domaines.

Traitez pip install comme une exécution de code. Un fichier .pth dans site-packages/ s’exécute à chaque démarrage de Python. Il n’y a pas d’opt-out. Il n’y a pas de sandbox. Si vous exécutez pip install dans un environnement CI avec accès aux identifiants, vous accordez une exécution de code arbitraire à chaque dépendance transitive du paquet. L’atténuation : exécutez pip install dans un environnement sans accès aux identifiants, puis copiez les paquets installés vers l’environnement qui en a besoin.

Utilisez des fichiers de verrouillage. L’analyse de FutureSearch a montré que les utilisateurs de uv (qui s’appuient sur des fichiers de verrouillage) ont rarement récupéré la version compromise, tandis que les utilisateurs de pip (qui résolvent vers la dernière version) l’ont récupérée constamment. Les fichiers de verrouillage ne sont pas une défense complète, mais ils préviennent l’exposition la plus courante : une contrainte de version >= non épinglée se mettant à jour silencieusement vers une version compromise.⁴

L’implication inconfortable

La campagne TeamPCP démontre que la sécurité de la chaîne d’approvisionnement n’est pas une préoccupation secondaire qui se situe derrière la sécurité applicative, la sécurité réseau et la protection des endpoints. Pour les organisations exécutant des agents IA avec accès aux outils, la chaîne d’approvisionnement est la surface d’attaque principale.

Un agent IA qui appelle pip install dans un environnement CI, récupère des URL ou installe des serveurs MCP compose des relations de confiance à l’exécution. Chaque opération porte sa propre autorisation. La composition peut ne pas la porter. Le paradoxe deploy-and-defend accélère cela : les organisations déploient les agents plus vite qu’elles n’auditent les chaînes de confiance que ces agents composent.

Le bogue de bombe de fork dans LiteLLM 1.82.8 est la seule raison pour laquelle quiconque a détecté cette attaque rapidement. Sans cette erreur d’implémentation, le voleur d’identifiants aurait tourné silencieusement à chaque invocation Python sur chaque système infecté. 46 996 installations en 46 minutes. 36 % des environnements cloud. 2 337 paquets en aval. L’attaquant a fait une seule erreur. La prochaine fois, il pourrait ne pas en faire.

Mise à jour — 31 mars 2026 : un vecteur différent, le même résultat

Six jours après la publication de cet article, npm a eu son incident suivant. Le 31 mars, le mainteneur d’axios, Jason Saayman, a révélé que son ordinateur personnel avait été compromis via une campagne ciblée d’ingénierie sociale suivie d’un malware de type cheval de Troie d’accès à distance. Les attaquants ont utilisé ses identifiants npm pour publier axios 1.14.1 et 0.30.4, qui injectaient tous deux une nouvelle dépendance appelée [email protected] qui installait un RAT multiplateforme sur macOS, Windows et Linux. Les versions malveillantes sont restées en ligne pendant environ trois heures avant que des contributeurs de la communauté ne trient l’incident et que npm ne les retire.¹⁶

Le vecteur axios était différent de TeamPCP. Il n’y avait pas de runner CI compromis, pas d’identifiant récolté depuis un scanner de sécurité tiers, pas de ver multi-écosystèmes. La campagne contre Saayman a duré environ deux semaines avant la publication, et la compromission a voyagé à travers l’appareil personnel du mainteneur directement vers le pipeline de publication npm. La remédiation a nécessité un effacement complet de tous ses appareils et la rotation de chaque identifiant sur chaque plateforme qu’il avait jamais utilisée, personnelle ou autre. L’infrastructure C2 était sfrclak[.]com sur 142.11.206.73:8000.¹⁶

La leçon structurelle est la même. La chaîne de confiance inclut désormais l’attention et la vigilance du mainteneur comme maillons, parce que des opérations individuellement légitimes se composent en comportement non autorisé lorsqu’un adversaire manipule un humain dans la chaîne. Les mesures d’atténuation que l’équipe axios adopte (publication OIDC, releases immuables, isolation des appareils)¹⁶ répondent au même écart de composition que Trivy vers LiteLLM a exposé : des identifiants de publication stockés là où ils peuvent être atteints par des adversaires qui ont déjà compromis quelque chose d’adjacent.

Trois heures. 46 minutes. Ce sont les fenêtres dans lesquelles les attaques modernes sur la chaîne d’approvisionnement opèrent maintenant. L’épinglage et les fichiers de verrouillage restent la défense principale : les utilisateurs d’axios qui avaient des installations fraîches en dehors de la fenêtre 00 h 21-03 h 15 UTC du 31 mars n’étaient pas affectés.¹⁶

FAQ

Comment vérifier si j’ai été affecté ?

Recherchez dans vos journaux CI et environnements locaux les versions 1.82.7 ou 1.82.8 de LiteLLM installées entre 10 h 39 et 11 h 25 UTC le 24 mars 2026. Si vous trouvez l’une ou l’autre version, changez chaque identifiant que le système pouvait atteindre – variables d’environnement, clés SSH, fichiers de configuration. Conseils officiels de LiteLLM : traitez tout système ayant exécuté les versions compromises comme entièrement compromis.⁵

Quel identifiant d’avis dois-je suivre ?

Suivez PYSEC-2026-2 dans OSV et la base de données d’avis PyPA. OSV donne également à l’incident l’alias MAL-2026-2144. Au 25 mars 2026, la page publique d’avis OSV ne liste pas d’alias CVE pour les versions malveillantes de LiteLLM, donc les équipes de réponse aux incidents devraient se baser d’abord sur les versions affectées, la fenêtre d’installation et PYSEC-2026-2.¹⁵

Les utilisateurs de LiteLLM Cloud ou du proxy Docker ont-ils été affectés ?

Non. LiteLLM Cloud et l’image officielle du proxy Docker épinglent les dépendances dans requirements.txt, empêchant la résolution automatique vers les versions compromises. Seuls les utilisateurs qui ont installé LiteLLM via pip install litellm (non épinglé) pendant la fenêtre de 46 minutes ont été affectés.⁵

Qu’est-ce qu’un fichier .pth et pourquoi est-il dangereux ?

Un fichier .pth est une fonctionnalité de Python pour configurer les chemins de recherche de modules. Le module site.py de Python lit et exécute tout fichier se terminant par .pth dans le répertoire site-packages/ pendant l’initialisation de l’interpréteur. L’exécution a lieu avant toute instruction d’import, avant tout code applicatif et avant tout sandbox de niveau Python. La bibliothèque standard Python documente le mécanisme, mais peu de développeurs d’applications savent qu’il existe. C’est une fonctionnalité légitime détournée en vecteur d’attaque.³

Est-ce lié à l’attaque sur la chaîne d’approvisionnement de Trivy ?

Oui. La compromission de LiteLLM était une conséquence directe de la compromission de Trivy. TeamPCP a compromis les Actions GitHub de Trivy le 19 mars, ce qui a récolté des identifiants CI/CD d’organisations exécutant Trivy dans leurs pipelines de build. L’un de ces identifiants était le token de publication PyPI de LiteLLM. L’attaquant a utilisé ce token pour publier les versions malveillantes de LiteLLM cinq jours plus tard.¹⁰

Qu’est-ce que TeamPCP ?

TeamPCP (également suivi comme DeadCatx3, PCPcat, ShellForce, CipherForce) est un groupe malveillant qui a mené une campagne multi-écosystèmes sur la chaîne d’approvisionnement en mars 2026, compromettant des paquets sur les Actions GitHub, Docker Hub, npm, Open VSX et PyPI. Le groupe a utilisé des techniques de récolte d’identifiants, de détournement de tags et de vers auto-propagateurs sur cinq écosystèmes de paquets en environ une semaine.⁶

Quel est le lien avec la sécurité des agents IA ?

Les agents IA qui installent des paquets, récupèrent des URL ou se connectent à des serveurs MCP composent des relations de confiance à l’exécution. Chaque opération porte sa propre attribution de permission. La composition de ces opérations peut produire un comportement non autorisé, comme démontré par l’exfiltration silencieuse (niveau agent), Clinejection (niveau CI/CD) et cette attaque (niveau chaîne d’approvisionnement). La surveillance comportementale à l’exécution, les listes d’autorisation de domaines et l’isolation des identifiants répondent à l’écart de composition à différentes couches de la pile.¹⁴

Sources