if ( !emtpy($headline_subheadline ) ) : ?>
Les attaquants ont utilisé des informations d’identification GitHub volées pour diffuser une version dérobée de la célèbre passerelle IA, exposant ainsi les secrets du cloud, de Kubernetes et de CI/CD.
endif; ?>
Des pirates ont détourné le pipeline de versions logicielles de LiteLLM, une passerelle d’IA open source populaire, pour distribuer des logiciels malveillants de vol d’informations d’identification, marquant la deuxième compromission de la chaîne d’approvisionnement du projet cette année malgré les mesures de sécurité introduites après une attaque précédente.
La version compromise, 1.107.0, a été distribuée via le Python Package Index (PyPI) et les images Docker officielles le 21 octobre. LiteLLM a déclaré que les packages Python malveillants sont restés disponibles pendant environ deux heures avant d’être supprimés, tandis que les images Docker concernées ont été retirées ou remplacées plus tard dans la journée.
Les images Docker concernées incluaient celles distribuées sous les balises les plus récentes, les plus récentes et les plus stables, étendant le risque aux déploiements qui ont extrait ces balises pendant la fenêtre d’exposition.
Selon la société de cybersécurité Aikido, les fichiers fournis avec le package compromis s’exécutaient automatiquement au démarrage de Python, même si une application n’importait pas LiteLLM. Le malware a été conçu pour collecter des informations sensibles sur les systèmes infectés, notamment les informations d’identification cloud et les clés API stockées dans la base de données de LiteLLM, donnant potentiellement aux attaquants l’accès à des services au-delà de la passerelle IA affectée.
Le paquet compromis contenait également un cheval de Troie d’accès à distance qui lançait un processus en arrière-plan pour récupérer et exécuter le code de l’infrastructure contrôlée par l’attaquant toutes les heures, selon Aikido. Cela pourrait permettre aux attaquants de continuer à exécuter des commandes sur les systèmes infectés après le vol initial des informations d’identification.
Dans son rapport d’incident, LiteLLM a déclaré que les attaquants avaient utilisé les informations d’identification GitHub volées associées à trois comptes de développeurs pour manipuler son pipeline de versions logicielles. Les informations d’identification volées ont permis de modifier le flux de travail de publication, qui a été redirigé vers un référentiel similaire contrôlé par un attaquant.
La société a déclaré que les attaquants pourraient avoir obtenu les informations d’identification à partir de journaux associés à un déploiement LiteLLM interne accessible sur Internet. Elle a également identifié les circonstances dans lesquelles Claude Code pourrait exposer les jetons d’authentification GitHub dans les réponses enregistrées ultérieurement par LiteLLM. Cependant, il n’a pas été établi comment les attaquants ont initialement accédé au déploiement.
LiteLLM a déclaré que l’incident avait été maîtrisé et que les clients utilisant son registre d’entreprises privées n’étaient pas affectés. Il a conseillé aux organisations exécutant le logiciel open source compromis de traiter leurs environnements comme potentiellement violés et de faire alterner les informations d’identification exposées plutôt que de se fier uniquement à la suppression du package malveillant.
Exposition plus large des entreprises
« Une passerelle LiteLLM compromise offre un point d’ancrage solide aux pirates informatiques et pourrait exposer bien plus que les clés API de l’IA », a déclaré Keith Prabhu, PDG de Confidis. Aikido a noté que le logiciel malveillant ciblait les jetons de compte de service Kubernetes et les secrets associés aux systèmes CI/CD, notamment GitLab et Jenkins.
L’étendue de toute compromission ultérieure peut dépendre des privilèges attribués au déploiement concerné et des informations d’identification dont il dispose.
« Une passerelle IA est une infrastructure d’entreprise privilégiée », a déclaré Sakshi Grover, directeur de recherche pour la sécurité des informations et des données chez IDC. « La centralisation de l’accès à plusieurs modèles peut améliorer la gouvernance, mais elle concentre également la confiance. »
Au-delà du vol d’identifiants, une passerelle compromise pourrait perturber les applications métier qui en dépendent, a déclaré Grover. L’enquête d’IDC sur la résilience et les dépenses futures des entreprises, menée en juillet 2026, a révélé que 95 % des entreprises interrogées dans le monde disposaient d’au moins un flux de travail en production financé par l’entreprise et activé par un agent.
Un défi plus vaste en matière de réponse aux incidents
Le composant d’accès à distance du logiciel malveillant pourrait rester actif même après la suppression du package compromis, ce qui compliquerait les efforts visant à déterminer si un système affecté peut être restauré en toute sécurité.
« Les RSSI ne devraient pas traiter cela simplement comme un exercice de nettoyage de packages », a déclaré Prabhu.
Il a recommandé d’identifier les déploiements exécutant des packages ou des images de conteneurs concernés, d’isoler les systèmes suspects et de préserver les preuves médico-légales avant de les reconstruire à l’aide d’un logiciel fiable.
Grover a averti que les équipes de sécurité devraient éviter de lancer Python ou pip dans des environnements suspectés d’être compromis, car les hooks de démarrage du malware pourraient s’exécuter à nouveau. Elle a recommandé d’identifier les packages concernés et les résumés d’images de conteneurs dans les environnements de production, les systèmes de développement et les exécuteurs CI.
« Les indicateurs manquants ne prouvent pas qu’un environnement est propre », a déclaré Grover.
Prabhu a recommandé d’examiner les journaux à la recherche de preuves d’accès persistant ou d’utilisation abusive d’informations d’identification volées. Il a déclaré que les organisations devraient alterner tous les secrets accessibles au déploiement compromis, y compris les informations d’identification associées à l’infrastructure cloud et aux pipelines de développement.
Grover a également recommandé de lier la télémétrie d’utilisation de l’IA aux journaux d’audit du cloud et des identités pour aider à identifier une éventuelle utilisation abusive des informations d’identification. Une consommation inhabituelle de jetons pourrait fournir une indication d’une activité non autorisée, même si les attaquants pourraient éviter de générer des augmentations notables des dépenses, a-t-elle déclaré.
Faiblesses de la chaîne d’approvisionnement logicielle
En mars, des versions malveillantes du package Python de LiteLLM ont été distribuées suite à une compromission que le projet a liée au scanner de sécurité Trivy utilisé dans son pipeline de versions logicielles.
Après cela, LiteLLM a renforcé son processus de publication de logiciels en déplaçant les versions vers un référentiel privé et en introduisant des images Docker signées. Cependant, les attaquants ont utilisé les informations d’identification GitHub volées pour modifier le flux de publication, qui a ensuite signé et publié le logiciel malveillant, a indiqué la société.
L’incident montre comment un code malveillant peut passer par un processus de signature de logiciel autorisé lorsque des attaquants compromettent le pipeline de publication. Une signature numérique valide peut vérifier qu’un artefact n’a pas été modifié depuis la signature, mais ne peut pas établir si le code était sûr au moment de sa signature.
« Les compromissions répétées de la chaîne d’approvisionnement montrent qu’un référentiel source fiable ne garantit pas que le package installé par les utilisateurs a été construit à partir de cette source », a déclaré Prabhu.
Prabhu a recommandé des versions signées cryptographiquement et soutenues par une provenance de construction vérifiable, ainsi qu’une protection plus renforcée des informations d’identification de publication.
Grover a déclaré que les entreprises devraient également inspecter les progiciels distribués et les images de conteneurs avant le déploiement, plutôt que de se fier uniquement à l’intégrité du référentiel source. Elle a recommandé de limiter les déploiements de production aux résumés de packages et d’images vérifiés et d’exiger une approbation indépendante pour les modifications apportées aux flux de travail de publication.
