Le “Hack” de 40 minutes proposé par LiteLLM menace encore 2 500 entreprises et 434 000 pipelines.

Pourquoi un compromis de 40 minutes sur PyPI est toujours important

Une téléchargement malveillant de courte durée peut encore exposer des secrets liés aux services en nuage, au Kubernetes et à l’IA dans des milliers d’organisations.

C’est là le problème essentiel. Les paquets défectueux étaient en ligne uniquement pendant…Environ 40 minutesEt LiteLLM a déjà publié une version définitive. Mais le point le plus important est la période d’exposition : CloudSEK a lié cet incident à plus de 2 500 entreprises.434 000 pipelines CI/CDpar le biais deEnviron 40 minutesL’accès aux chaînes d’approvisionnement contaminées est un problème majeur. Dans les environnements où les processus de compilation, de déploiement et d’utilisation des outils de modélisation sont automatisés, cela devient bien plus important que la période de publication courte.

Une évacuation sécurisée est possible, mais cela ne remet pas en question les expériences de exposition qui ont déjà eu lieu. Le FBI a donné des alertes.Les acteurs affiliés ont tendance à utiliser les identifiants obtenus comme armes.Longtemps après l’intrusion initiale, c’est pourquoi une correction immédiate reste importante.

Comment LiteLLM est devenu un vecteur de violation des données d’entreprise

La fenêtre de publication était courte ; le chemin de confiance n’était pas…

On24 mars 2026Les roues de LiteLLM compromises étaient publiées sur PyPI pendant environ 40 minutes, avant que PyPI ne les mette en quarantaine. Dans les écosystèmes Python, c’est le temps nécessaire pour résoudre les dépendances, télécharger les roues, et exécuter les scripts de post-installation.

Les artefacts affectés sont clairs : litellm==1.82.7 et litellm==1.82.8. LiteLLM se situe entre les applications et les principaux fournisseurs de LLM.Abstraire les différences entre les fournisseurs de LLMC’est justement pour cette raison qu’il peut apparaître dans les processus d’IA et d’infrastructure sensibles.

TeamPCP a transformé un compromis en un autre.

Ce n’était pas une uploadeur de fichiers mauvais au hasard. Les preuves montrent que…Les tokens volés dans le compromis de Trivy ont été utilisés pour compromettre le pipeline de publication sur PyPI de LiteLLM.En termes simples, les attaquants ont d’abord utilisé une application de sécurité compromise, puis ont utilisé ces identifiants pour corrompre l’application suivante dans la chaîne.

Une fois publiés, les paquets malveillants permettaient une répétition.Attaque en trois étapes:

1. Récolte des qualifications.
2. Essayer de se déplacer latéralement entre les clusters Kubernetes.
3. Installez un backdoor persistant de Systemd qui vérifie régulièrement s’il y a des charges utiles supplémentaires.

Ce modèle est plus important que la courte période pendant laquelle les paquets étaient visibles sur PyPI.

Pourquoi la menace reste-t-elle active après la correction

LiteLLM dit :Une nouvelle version propre de LiteLLM est maintenant disponible (v1.83.0)Grâce à une pipeline CI/CD v2 renforcée. Cela améliore les versions futures, mais cela ne peut pas annuler les installations qui ont déjà eu lieu.

Les dommages possibles sont encore nombreux :Credences AWS, Google Cloud et Microsoft AzureLes clés SSH, les tokens Kubernetes, les secrets CI/CD, les identifiants des repositories, les variables d’environnement et les clés LLM/API ont tous été exposés. Dans les environnements basés sur l’intelligence artificielle, ces secrets permettent le cycle de construction à déploiement. Ainsi, la contamination peut persister même après que le paquet original a été retiré.

Que doit se passer ensuite ?

Pourquoi cela est-il important au-delà d’une seule bibliothèque open-source ?

LiteLLM n’était pas une erreur isolée. Il correspondait à un modèle plus large du TeamPCP, qui repose sur…Vol de credences en cascadeAvec le groupe cibléOutils de développement et de sécurité largement utiliséset en les utilisant pourInjecter du malware dans les pipelines CI/CD sans déclencher les contrôles de sécurité standards.Cela rend cela moins une question de réputation pour une seule bibliothèque, et plus un risque structurel au sein des chaînes d’approvisionnement logiciel.

Mesures de correction immédiates

Si vous utilisez des versions affectées de LiteLLM ou si vous exécutezProcessus automatisés qui permettent de créer, tester et déployer du code logicielTraitez l’incident comme quelque chose de actif, jusqu’à ce que vous puissiez valider votre environnement.

Priorités de correction : – Rotater des éléments qui pourraient être utilisés pour des attaques : tokens cloud, clés SSH, secrets Kubernetes, identifiants de répertoires, et clés LLM/API. En effet, TeamPCP a effectué des récupérations de ces données.Tokens d’accès aux nuages, clés SSH et secrets Kubernetes– Reconstruire à partir de sources propres, plutôt que de réutiliser des environnements ou des installations stockées liées au flux compromis. – Auditer les pipelines pour détecter les faiblesses de confiance, y compris les sources de paquets, l’accès des utilisateurs et les méthodes de publication des logiciels. – Imposer des permissions minimales pour les secrets dans le cadre du CI/CD, afin que les machines de exécution aient uniquement l’accès nécessaire pour chaque tâche. – Ajouter des contrôles d’intégrité des artefacts, tels que le verrouillage des checksums et des contrôles plus stricts lors de la publication.

Qu’est-ce qui pourrait réduire l’urgence ?

Le principal point de vigilance est l’abus ultérieur des identifiants volés. Si les enquêtes montrent que…Les acteurs affiliés ont tendance à utiliser les identifiants obtenus comme armes.Cet incident doit être considéré comme une menace continue, et non comme un cas clos.