KICS et LiteLLM compromis : deux nouvelles attaques supply chain qui confirment un changement d’échelle
À peine le temps d’analyser la compromission de Trivy qu’une nouvelle vague d’attaques frappe déjà d’autres briques très utilisées. Cette fois, deux incidents distincts attirent l’attention : la compromission de la GitHub Action liée à KICS/Checkmarx et la publication sur PyPI de versions malveillantes de LiteLLM. Ces deux affaires ne sont pas de simples accidents isolés. Elles montrent au contraire une campagne qui change de terrain, réutilise les mêmes mécanismes et vise toujours la même ressource : vos secrets, vos tokens, vos runners, vos environnements cloud et vos clusters Kubernetes.
Le plus inquiétant n’est pas seulement le fait que des projets populaires aient été touchés. Le plus inquiétant, c’est la démonstration très concrète qu’aujourd’hui, un attaquant n’a plus besoin de compromettre votre code applicatif pour vous atteindre. Il lui suffit d’empoisonner un maillon de confiance que vous consommez automatiquement : une GitHub Action, un package PyPI, une image ou un outil téléchargé depuis un dépôt réputé légitime.
Une nouvelle vague après Trivy
Le 23 mars 2026, Wiz et Sysdig ont documenté une nouvelle compromission touchant
l’écosystème Checkmarx/KICS. Selon leurs analyses, une action GitHub liée à
Checkmarx a été empoisonnée avec un credential stealer identique à celui
déjà observé dans la campagne Trivy. Sysdig explique que l’activité observée
dans Checkmarx/ast-github-action reprend la même chaîne d’exécution, le même
mode d’exfiltration et les mêmes objectifs que l’attaque précédente. Wiz précise
de son côté que 35 tags de release de l’action KICS ont été détournés entre
12:58 et 16:50 UTC le 23 mars 2026.
Le 24 mars 2026, une autre alerte est tombée : les versions 1.82.7 et
1.82.8 du package LiteLLM publiées sur PyPI ont été trojanisées.
FutureSearch indique que la version 1.82.8 a été publiée à 10:52 UTC et
contenait un fichier .pth malveillant nommé litellm_init.pth, exécuté
automatiquement à chaque démarrage d’un interpréteur Python lorsque le package
est installé. Le même billet précise ensuite que la version 1.82.7 était
elle aussi compromise.
Ces deux attaques utilisent des vecteurs différents, mais racontent la même histoire : l’attaquant ne cherche plus seulement à toucher un projet. Il cherche à s’insérer dans les flux de confiance automatiques des développeurs et des pipelines.
Ce qui s’est passé côté KICS
Dans le cas de KICS/Checkmarx, le vecteur d’attaque passe par GitHub
Actions. Les workflows qui consommaient l’action via un tag mutable
pouvaient récupérer du code désormais contrôlé par l’attaquant. Sysdig détaille
une chaîne d’exécution très proche de celle vue chez Trivy : Runner.Worker → bash → setup.sh → curl POST, avec exfiltration d’un archive nommée
tpcp.tar.gz vers un domaine typosquatté, ici checkmarx[.]zone.
Le malware ne s’arrêtait pas à un simple vol de variables d’environnement. Sysdig mentionne plusieurs comportements caractéristiques : lecture de la mémoire des processus du runner, requêtes vers l’Instance Metadata Service pour récupérer d’éventuels identifiants cloud temporaires, recherche de webhooks Slack et Discord dans le workspace, puis exfiltration chiffrée vers l’infrastructure de l’attaquant. Wiz et Sysdig considèrent que cette vague est cohérente avec l’activité déjà attribuée à TeamPCP.
Autrement dit, si votre workflow utilisait un tag de type @v2, @v2.3.28 ou
équivalent, vous aviez un point faible structurel : vous faisiez confiance à
une référence réinscriptible. Le code réellement exécuté pouvait changer après
coup sans modification visible de votre pipeline. Sysdig rappelle
explicitement que le pinning sur SHA de commit aurait résisté à cette
technique, contrairement aux tags.
Ce qui s’est passé côté LiteLLM
Le cas LiteLLM est encore plus brutal, car il touche PyPI et un package
Python très largement utilisé dans l’écosystème IA. FutureSearch explique que la
version 1.82.8 contenait un fichier .pth malveillant déclenché automatiquement
au lancement de Python. C’est un point clé : ici, l’installation seule pouvait
suffire à activer le code malveillant, sans même avoir besoin d’un import litellm. Simon Willison note par ailleurs que pour 1.82.7, le code
malveillant se trouvait dans proxy/proxy_server.py, ce qui nécessitait cette
fois un import ou une exécution de ce composant pour produire l’effet.
FutureSearch décrit ensuite un malware en trois temps. D’abord la collecte :
clés SSH, fichiers .env, identifiants AWS, GCP et Azure, configurations
Kubernetes, mots de passe de bases de données, historique shell, .gitconfig,
portefeuilles crypto et tout fichier ressemblant à un secret. Ensuite
l’exfiltration, chiffrée avec AES-256-CBC et une clé publique RSA 4096
bits, vers le domaine models.litellm.cloud, présenté comme non légitime.
Enfin la persistance et le mouvement latéral : si un token de service
account Kubernetes est disponible, le malware tente de lire les secrets du
cluster puis de créer des pods privilégiés dans kube-system afin d’installer
un backdoor persistant sur les nœuds.
On n’est donc plus du tout dans le scénario classique du package malveillant opportuniste qui essaye juste de voler un token PyPI ou une variable d’environnement. Ici, on voit un malware pensé pour escalader, survivre et rebondir dans les environnements modernes : postes de dev, pipelines, cloud, conteneurs et Kubernetes.
Pourquoi ces deux incidents sont probablement liés
Le lien entre KICS et LiteLLM ne repose pas uniquement sur une
intuition. Plusieurs sources indiquent que LiteLLM réutilise la même logique
malveillante que la campagne précédente. Wiz mentionne directement que les
paquets litellm trojanisés contiennent “the same functionality as the
previous operation”, avec un nouveau domaine d’exfiltration. GitGuardian
affirme également que, le 24 mars, la campagne s’est déplacée vers PyPI et que
les versions 1.82.7 et 1.82.8 de LiteLLM contenaient le même
infostealer que celui déjà vu plus tôt dans la campagne.
Le schéma est cohérent :
- même finalité : voler des secrets, tokens et accès réutilisables ;
- même logique d’exfiltration : archive chiffrée envoyée vers un domaine contrôlé par l’attaquant ;
- même adaptation au contexte : GitHub Actions pour KICS, PyPI pour LiteLLM ;
- même stratégie de confiance détournée : empoisonner un outil déjà accepté dans les chaînes de build et de développement.
La vraie leçon, c’est que l’attaquant n’exploite pas seulement une faille technique. Il exploite surtout une faille de posture : la confiance implicite accordée à tout ce qui provient d’un projet populaire, d’un compte mainteneur ou d’un écosystème connu.
Pourquoi ces attaques sont particulièrement dangereuses
Ces deux incidents sont dangereux pour une raison simple : ils frappent au bon endroit. Pas sur la périphérie. Pas sur une dépendance obscure. Mais au cœur des mécanismes que beaucoup d’équipes ont industrialisés :
- installation automatique de packages depuis PyPI ;
- usage de GitHub Actions tierces par simple référence de tag ;
- runners CI/CD capables d’accéder aux secrets de build ;
- environnements cloud où l’IMDS est accessible ;
- clusters Kubernetes où les service accounts disposent encore de privilèges excessifs.
Quand une action GitHub ou un package Python est compromis, ce n’est pas juste votre dépôt qui est exposé. Ce sont aussi potentiellement :
- vos secrets GitHub et vos PAT ;
- vos identifiants cloud temporaires ou persistants ;
- vos accès à des registres d’images ;
- vos tokens PyPI ou npm ;
- vos webhooks ;
- vos clusters Kubernetes ;
- et, dans le cas de LiteLLM, vos postes de développeurs et environnements IA locaux.
GitGuardian rappelle par ailleurs que l’exposition des secrets continue de croître fortement, avec 29 millions de secrets détectés sur GitHub public en 2025 dans son rapport 2026. Ce contexte rend ce type de campagne encore plus rentable pour les attaquants : plus il y a de secrets qui traînent dans les environnements de build et de dev, plus la compromission d’un seul maillon devient payante.
Les erreurs de défense que ces incidents mettent en lumière
La première erreur est de croire qu’un dépôt populaire ou un mainteneur connu suffit comme garantie. Dans les deux cas, c’est précisément cette réputation préalable qui a rendu l’attaque efficace.
La deuxième erreur est de confondre référence de version et intégrité. Un tag GitHub n’est pas une preuve d’immuabilité. S’il peut être déplacé, il peut devenir une arme. Sysdig insiste clairement sur ce point : le pinning par SHA complet protège contre cette classe d’attaque là où un simple tag ne protège pas.
La troisième erreur est de considérer qu’un package installé n’est dangereux
qu’au moment où on l’exécute explicitement. L’incident LiteLLM montre
exactement l’inverse : un fichier .pth peut faire exécuter du code dès le
démarrage de Python.
La quatrième erreur est de penser que le problème se limite au dépôt compromis. En réalité, l’objectif est souvent de rebondir : voler un token sur un runner, l’utiliser pour compromettre d’autres dépôts, empoisonner d’autres actions, pivoter vers d’autres écosystèmes. C’est précisément le scénario mis en avant par Sysdig pour expliquer la propagation entre Trivy et Checkmarx, puis relayé par les observations sur LiteLLM.
Que faire immédiatement si vous êtes concernés
Si vous utilisez KICS via GitHub Actions, commencez par identifier tous
les workflows qui référencent les actions Checkmarx/KICS concernées, en
particulier via des tags. Sysdig recommande d’auditer les exécutions
entre le 19 et le 23 mars 2026, de rechercher les indicateurs comme
tpcp.tar.gz, checkmarx.zone ou d’éventuels dépôts tpcp-docs, puis de
faire tourner tous les secrets accessibles à ces runners.
Si vous utilisez LiteLLM, vérifiez immédiatement la version installée.
FutureSearch recommande de contrôler pip show litellm, de purger les
caches pip ou uv, de rechercher litellm_init.pth, puis de vérifier toute
trace de persistance comme ~/.config/sysmon/sysmon.py ou
~/.config/systemd/user/sysmon.service. En environnement Kubernetes, il
faut aussi auditer kube-system pour repérer d’éventuels pods node-setup-*.
Tous les identifiants présents sur la machine ou le cluster doivent être
considérés comme compromis.
Ce qu’il faut changer durablement
Ces incidents ne se règlent pas uniquement avec une rotation de secrets et un post-mortem. Ils imposent un changement de posture.
1. Réduire la confiance implicite
Arrêtez de considérer GitHub, PyPI ou un compte mainteneur comme des zones automatiquement sûres. Ce sont des canaux de distribution, pas des garanties. Un projet populaire peut être compromis comme n’importe quel autre.
2. Pinner les GitHub Actions sur des SHAs immuables
Pour GitHub Actions, le minimum aujourd’hui est le pinning sur SHA complet, pas sur tag. C’est une exigence de base, pas une option avancée.
3. Isoler les runners et limiter les secrets
Les runners CI/CD doivent être traités comme des environnements à haut risque : réseau sortant limité, accès IMDS restreint ou désactivé, secrets minimaux, comptes éphémères, rotation fréquente et journalisation fine. Sysdig rappelle notamment que l’accès IMDS depuis les runners a été utilisé dans cette campagne pour récupérer des identifiants cloud.
4. Contrôler les dépendances avant exécution
Le vrai sujet n’est plus seulement de savoir quoi vous utilisez, mais comment vous l’introduisez dans vos chaînes. Il faut une validation préalable des packages, actions, images et outils tiers avant toute exécution dans un contexte de confiance. Les incidents récents montrent qu’attendre l’exécution pour réagir est déjà trop tard.
5. Détecter le comportement, pas seulement la réputation
Sysdig souligne un point très important : les domaines d’exfiltration
utilisés étaient nouveaux et pouvaient apparaître “propres” dans les feeds de
réputation. La détection doit donc porter sur les comportements : lecture
IMDS depuis un runner, curl POST binaire vers un domaine inattendu, accès
anormal aux secrets Kubernetes, création de pods privilégiés, etc.
Ce que ces attaques disent de l’open source en 2026
Il faut éviter deux excès.
Le premier serait de conclure que l’open source est le problème. Ce n’est pas sérieux. L’open source reste au cœur de l’infrastructure moderne, et la transparence du code permet aussi d’analyser et de comprendre plus vite certaines attaques.
Le second excès serait de continuer comme avant sous prétexte que “ça n’arrive qu’aux autres”. Là non plus, ce n’est plus crédible. Les campagnes récentes montrent que les attaquants savent très bien identifier les nœuds de confiance à forte valeur : actions GitHub populaires, packages Python massivement utilisés, outils de sécurité, composants de build, dépendances transitives et outils pour l’IA.
La vraie question n’est donc pas “faut-il encore utiliser de l’open source ?”. La vraie question est : quelle quantité de confiance automatique acceptez-vous encore dans votre chaîne logicielle ?
Conclusion
Les compromissions de KICS et de LiteLLM confirment une tendance lourde : les attaques supply chain ne visent plus seulement des bibliothèques obscures ou des paquets typosquattés. Elles frappent désormais des outils centraux, utilisés dans les pipelines, dans les environnements de développement, dans le cloud et dans les stacks IA.
Dans le cas de KICS, l’attaque exploite la confiance placée dans une GitHub Action versionnée par tag. Dans le cas de LiteLLM, elle abuse la confiance accordée à PyPI et à un package Python largement adopté. Dans les deux cas, le résultat est le même : vol de secrets, compromission potentielle des environnements et capacité de rebond vers d’autres systèmes.
Le signal est clair : il ne suffit plus de scanner son code, de signer quelques artefacts ou d’ajouter un outil de plus dans le pipeline. Il faut revoir la posture globale de consommation des dépendances, des actions, des packages et des images. L’époque où l’on pouvait faire implicitement confiance à tout ce qui est populaire, bien étoilé ou simplement hébergé sur GitHub est terminée.
Attention à vos usages de tous les outils open source présents sur GitHub.
Sources
- Wiz — KICS GitHub Action Compromised: TeamPCP Supply Chain Attack
- Sysdig — TeamPCP expands: Supply chain compromise spreads from Trivy to Checkmarx GitHub Actions
- FutureSearch — Supply Chain Attack in litellm 1.82.8 on PyPI
- GitGuardian — State of Secrets Sprawl Report 2026
- GitGuardian Blog — The State of Secrets Sprawl 2026
- The Hacker News — TeamPCP Hacks Checkmarx GitHub Actions Using Stolen Credentials
- Wiz — Trivy Compromised by TeamPCP
- Rami McCarthy — Incident Timeline // Trivy Supply Chain Attack