Attaques contre la chaîne d’approvisionnement via Trivy et LiteLLM : protection du pipeline CI/CD contre la vulnérabilité CVE-2026-33634

Des millions de pipelines de développement logiciel automatisés s’appuient sur des outils de sécurité, comme Trivy et Checkmarx AST, intégrés au processus de compilation. Et ce sont précisément ces solutions réputées fiables qui ont récemment servi de point d’entrée à l’une des attaques les plus importantes et les plus dangereuses jamais perpétrées contre les chaînes d’approvisionnement. Dans cet article, nous expliquons comment auditer les flux de travail automatisés et sécuriser l’infrastructure cloud d’une entreprise.

Chronologie de l’attaque et conséquences connues

Le 19 mars, une attaque ciblée contre la chaîne d’approvisionnement a été menée via Trivy, un outil open source d’analyse des vulnérabilités largement utilisé dans les pipelines CI/CD. Les pirates, un groupe connu sous le nom de TeamPCP, ont réussi à injecter un programme malveillant dans les images Docker et les flux de travail officiels GitHub Actions associés à Trivy. En conséquence, chaque analyse automatisée du pipeline déclenchait un programme malveillant qui dérobait des clés SSH, des jetons d’accès au cloud, des portefeuilles de cryptomonnaies ainsi que d’autres données précieuses sur les systèmes compromis. Compte tenu du caractère critique de l’incident, celui-ci s’est vu attribuer l’identifiant CVE-2026-33634, avec un score CVSS4B de 9,4, soit un score proche du maximum.

Plus tard dans la journée, l’équipe de Trivy a détecté l’attaque et supprimé les éléments malveillants des canaux de distribution, mettant ainsi fin à cette phase de l’attaque. Cependant, les pirates avaient déjà réussi à s’introduire dans les environnements de nombreux utilisateurs de Trivy.

Le 23 mars, un incident similaire a été découvert dans un autre outil de sécurité des applications : une GitHub Action pour Checkmarx KICS et pour Checkmarx AST. Trois heures plus tard, le code malveillant y avait aussi été supprimé. TeamPCP a également réussi à compromettre les extensions OpenVSX prises en charge par Checkmarx : cx-dev-assist 1.7.0 et ast-results. Les informations divergent quant à la date de résolution de cette partie de l’incident.

Le 24 mars dernier, un projet très populaire utilisant l’analyse de code de Trivy, la passerelle d’IA LiteLLM (une bibliothèque universelle permettant d’accéder à divers fournisseurs LLM), a fait l’objet d’une attaque. Les versions 1.82.7 et 1.82.8 téléchargées dans le dépôt PyPI ont été compromises. Ces versions ont été accessibles au public pendant environ cinq heures.

Toutefois, le fait que l’attaque n’ait duré que quelques heures n’est pas une raison pour la minimiser. Compte tenu de la popularité des projets concernés, le code malveillant pourrait avoir été exécuté des milliers de fois, y compris au sein de l’infrastructure de très grandes entreprises.

Les pirates ont ainsi pu installer des portes dérobées persistantes dans des clusters Kubernetes, mais aussi lancer le ver CanisterWorm, capable de se répliquer automatiquement, à travers l’écosystème npm de JavaScript.

Le code des pirates présente des capacités destructrices qui effacent un cluster Kubernetes et tous ses nœuds s’il détecte soit le fuseau horaire de Téhéran, soit le farsi comme langue principale sur le système compromis. Dans d’autres régions, le programme malveillant se contente de voler des données à l’aide du ver CanisterWorm.

Selon les experts, plus de 20 000 dépôts sont considérés comme étant potentiellement vulnérables. Les pirates affirment avoir dérobé des centaines de gigaoctets de données et plus d’un demi-million de comptes.

Comment Trivy a été attaqué

Pour pirater Trivy, les pirates ont utilisé des identifiants dérobés lors d’un incident précédent. La précédente compromission de Trivy, survenue fin février, n’avait probablement pas été totalement maîtrisée, et les pirates (le même groupe TeamPCP) sont revenus à la charge avec une nouvelle attaque. Selon les développeurs de Trivy, Aqua Security, étant donné que les identifiants étaient progressivement supprimés à la suite de l’incident précédent, les pirates auraient été en mesure de générer de nouveaux jetons d’accès avant que les anciens, compromis, n’aient été révoqués.

Le groupe TeamPCP a donc pu compromettre les GitHub Actions utilisées dans les pipelines CI/CD. À l’aide d’identifiants dotés de droits d’écriture de tags, les pirates ont modifié de force 76 des 77 tags de version dans le répertoire aquasecurity/trivy-action, ainsi que les sept tags du répertoire aquasecurity/setup-trivy, redirigeant ainsi les versions fiables existantes vers des commits malveillants. On retrouve ici des tactiques observées lors de la campagne Shai-Hulud 2.0. Ainsi, les flux de travail tout au long du pipeline ont commencé à exécuter le code des pirates, alors que les métadonnées de la version ne présentaient aucun changement visible.

Parallèlement, les pirates ont publié une version binaire infectée de Trivy (v0.69.4) sur les canaux de distribution officiels, notamment GitHub Releases et les registres de conteneurs.

Compromission de LiteLLM

La compromission de LiteLLM, l’outil populaire d’accès aux modèles de langage, pourrait à elle seule déclencher une vague massive d’attaques à travers l’ensemble des projets qui l’utilisent. L’attaque a eu lieu le 24 mars 2026, lorsque TeamPCP a directement publié des versions malveillantes de la bibliothèque (1.82.7 et 1.82.8) sur PyPI. Entre 10 h 39 UTC et 16 h 00 UTC, ces paquets compromis contenaient des programmes malveillants qui volaient des identifiants. Ces virus étaient intégrés au fichier proxy_server.py, et la version 1.82.8 contenait également un fichier litellm_init malveillant. Les données volées ont été transférées vers le serveur models.litellm[.]cloud.

Les clients utilisant LiteLLM Cloud ou l’image Docker officielle de LiteLLM Proxy n’ont pas été affectés en raison du verrouillage strict des versions, tandis que les développeurs et les projets en aval ayant installé des versions non verrouillées via pip pendant la période indiquée ont été compromis.

En l’espace de trois heures, les paquets malveillants ont été supprimés du dépôt PyPI, et l’équipe LiteLLM a suspendu les nouvelles versions, renouvelé les identifiants d’accès et mis en place une procédure externe de gestion des incidents. Il est recommandé aux équipes qui utilisent LiteLLM dans leurs projets de vérifier dès que possible la présence de l’indicateur de compromission litellm_init.pth et de remplacer régulièrement tous les secrets potentiellement compromis.

Fonctionnalités du programme malveillant TeamPCP Cloud Stealer

Les pirates ont ajouté une nouvelle logique aux GitHub Actions et à l’exécutable Trivy tout en conservant les fonctionnalités d’origine. Les résultats de l’analyse de vulnérabilité effectuée via Trivy semblaient normaux, mais en réalité, des données sensibles étaient recherchées et extraites. Le code malveillant effectuait les opérations suivantes :

• effectuer une reconnaissance (collecte de données réseau et de variables d’environnement) ;
• rechercher des jetons et des identifiants pour accéder aux environnements cloud AWS et GCP ;
• analyser la mémoire (/proc/*/mem) afin d’extraire les informations confidentielles stockées dans la mémoire des processus Runner.Worker et Runner.Listener ;
• extraire les secrets Kubernetes (/run/secrets/kubernetes.io/serviceaccount) ;
• collecter les données nécessaires à la connexion aux serveurs de bases de données (MySQL, PostgreSQL, MongoDB, Redis, Vault) ;
• récupérer toutes les autres clés API et secrets contenus dans les fichiers d’environnement et les fichiers de configuration CI/CD (.env, .json, .yml) ;
• rechercher des webhooks pour les canaux Slack et Discord ;
• rechercher des données relatives aux portefeuilles de cryptomonnaies (variables liées à la blockchain Solana, ainsi que les données rpcuser et rpcpassword).

Les données collectées ont été chiffrées puis téléchargées sur un serveur dont le nom ressemblait à celui des développeurs de Trivy (scan.aquasecurtiy[.]org). En guise de solution de secours, les pirates ont fourni une méthode permettant de télécharger des données vers un dépôt nommé docs-tpcp.

L’attaque contre CheckMarx et LiteLLM a utilisé une tactique semblable à celle employée pour d’autres domaines de typosquattage : models.litellm[.]cloud et checkmarx[.]zone.

Vous trouverez une analyse technique détaillée du programme malveillant, ainsi que les indicateurs de compromission, dans l’article rédigé par notre expert sur le blog de Securelist.

Stratégies d’intervention et de défense pour la vulnérabilité CVE-2026-33634

Les vérifications basées sur les signatures et l’analyse des dépendances actuellement utilisées dans les registres publics ne suffisent plus, car le code malveillant a été injecté directement dans des actions fiables et signées, et a échappé à la détection jusqu’à ce qu’une surveillance comportementale soit mise en place. Les pipelines CI/CD sont désormais le « nouveau périmètre » de sécurité.

Mesures immédiates. Assurez-vous que tous les flux de travail utilisent des versions sécurisées (binaire Trivy 0.69.3, trivy-action 0.35.0, setup-trivy 0.2.6).

Les administrateurs de pipelines CI/CD et les équipes de sécurité doivent immédiatement passer en revue leurs dépendances vis-à-vis des solutions Checkmarx (kics-github-action, ast-github-action) et Trivy (setup-trivy et trivy-action). Si les flux de travail faisaient référence à un tag de version plutôt qu’à un hachage SHA particulier, passez attentivement en revue les journaux d’exécution de vos flux de travail pour la période durant laquelle l’attaque de la chaîne d’approvisionnement était active.

Nous vous recommandons également de vérifier vos journaux réseau pour détecter tout trafic vers les domaines scan.aquasecurtiy[.]org, checkmarx[.]zone et models.litellm[.]cloud. La présence d’un tel trafic indique que des données sensibles ont été extraites.

Si un dépôt nommé « docs-tpcp » est apparu sur le compte GitHub de l’organisation, cela peut également indiquer qu’une violation de données a eu lieu.

Vérifiez si les hôtes et les clusters présentent des signes de compromission : présence de fichiers ~/.config/sysmon/sysmon.py ou de pods suspects dans Kubernetes.

Videz le cache et faites l’inventaire des modules PyPI : recherchez ceux qui sont malveillants et restaurez les versions saines.

Dans tous les cas, il convient de mener une recherche proactive des menaces, en partant du principe que les systèmes ont été compromis et que les pirates ont rapidement progressé au sein des systèmes touchés.

Il est recommandé de restaurer les environnements concernés à partir de sauvegardes vérifiées.

Verrouillage des dépendances et gestion des secrets. Assurez-vous que les versions exactes des dépendances sont verrouillées à l’aide de hachages cryptographiques dans tous les pipelines et fichiers Dockerfile. Nous vous recommandons de remplacer les jetons à longue durée de vie par des identifiants à courte durée de vie à l’aide d’un outil de gestion des secrets, et de mettre en place des intégrations OIDC dans la mesure du possible. Limitez au maximum l’injection de données sensibles dans l’environnement d’exécution. Ne le faites que lorsque cela est absolument nécessaire. Assurez-vous que les secrets ne sont pas stockés sur le disque ni dans des fichiers temporaires, et qu’ils ne sont pas réutilisés dans différents processus.

Renouvelez tous les identifiants susceptibles d’avoir été compromis : clés API, variables d’environnement, clés SSH, jetons de compte de service Kubernetes et autres secrets.

Autres mesures de sécurité. Autorisez uniquement l’utilisation des GitHub Actions figurant sur une liste approuvée par l’organisation et bloquez les nouveaux processus non vérifiés. Configurez GITHUB_TOKEN et les autres clés d’accès en respectant le principe du moindre privilège. N’accordez pas d’autorisations d’écriture sauf en cas d’absolue nécessité.

Pour renforcer la sécurité des GitHub Actions, plusieurs outils open source sont disponibles :

• zizmor : un outil d’analyse statique et de détection des erreurs de configuration dans les GitHub Actions ;
• gato et Gato-X : deux versions d’un outil permettant d’identifier les pipelines présentant des vulnérabilités structurelles ;
• allstar : une application GitHub, développée par OpenSSF, permettant de configurer et d’appliquer des stratégies de sécurité au sein des organisations et des dépôts GitHub.

Si vous souhaitez en savoir plus sur les attaques visant la chaîne d’approvisionnement, nous vous invitons à consulter notre rapport d’analyse Réaction en chaîne : sécuriser l’écosystème numérique mondial à l’ère de l’interdépendance. Ce rapport s’appuie sur les analyses d’experts techniques et met en évidence les risques auxquels les organisations sont souvent confrontées au niveau de leur chaîne d’approvisionnement et de leurs relations de confiance, les lacunes qui subsistent en matière de protection, ainsi que les stratégies à mettre en œuvre pour renforcer la résilience face à ce type de menaces.