Français
L’industrie de l’IA consacre beaucoup de temps à débattre du modèle qui donne les meilleures réponses. Cette semaine, la question la plus urgente est de savoir qui pourrait être reparti avec des éléments utilisés pour les produire.
Mercor a confirmé un incident de sécurité lié à un logiciel LiteLLM compromis. Un acteur de l’extorsion fait la publicité de ce qu’il présente comme des données volées à Mercor. Ce sont des faits graves. Le butin annoncé n’est toutefois pas un inventaire vérifié des secrets de tous les grands laboratoires d’IA.
Une intrusion, une vente aux enchères annoncée et une enquête inachevée
The Register a rapporté le 2 avril que Mercor avait reconnu avoir été touchée par l’attaque de la chaîne d’approvisionnement de LiteLLM. L’entreprise disait avoir contenu et corrigé l’incident et fait appel à des spécialistes externes de l’investigation numérique. Son enquête se poursuivait.
Un acteur utilisant le nom Lapsus$ affirmait détenir environ quatre téraoctets de documents de Mercor et les proposait à la vente, dont du prétendu code source. Le volume et le contenu annoncés doivent être considérés comme les affirmations du vendeur. La confirmation d’un incident par Mercor n’authentifie pas indépendamment toutes les catégories de fichiers de cette annonce et n’établit pas le lien précis entre l’extorqueur et la compromission initiale.
Les argumentaires commerciaux de criminels sont un endroit singulier où exiger des descriptions de produits fiables. Malheureusement, ils savent aussi très bien faire les gros titres.
Pourquoi un fournisseur de données pour l’IA compte
WIRED a rapporté le 3 avril que Meta avait suspendu son travail avec Mercor pendant son enquête. Mercor fournit des jeux de données d’entraînement produits par des humains à des entreprises d’IA, dont OpenAI et Anthropic. OpenAI a indiqué à WIRED qu’elle enquêtait tout en poursuivant les projets, et que les données de ses utilisateurs n’étaient pas touchées. Le reportage n’établissait pas si les éléments exposés aideraient sensiblement un concurrent.
Pensez à la différence entre voler le plat terminé d’un restaurant et obtenir certaines notes de travail de sa cuisine. Ces notes pourraient être précieuses. Leur valeur dépend de ce qu’elles contiennent réellement, de leur actualité et de la possibilité pour quelqu’un d’autre de les exploiter. Un dossier intitulé « sauce secrète » pourrait contenir une recette, un tableau d’achats ou un JPEG très décevant.
Les exemples d’entraînement, les supports d’évaluation et les instructions peuvent compter sans constituer une recette complète pour reproduire un modèle. Passer de « un fournisseur a subi une intrusion » à « n’importe quel acheteur peut désormais cloner les meilleurs systèmes d’IA » exige des preuves qui manquent ici.
La pause de Meta rapportée par la presse est donc significative en tant que réponse à l’incertitude. Elle ne prouve pas que toutes ses méthodes d’entraînement ont été volées et n’annonce pas non plus la fin définitive de la relation.
La mise à jour empoisonnée est arrivée le 24 mars
Selon l’avis d’incident de LiteLLM, les versions malveillantes 1.82.7 et 1.82.8 ont été publiées sur le Python Package Index le 24 mars. Les responsables du projet ont relié l’incident à la compromission de Trivy, une dépendance de sécurité utilisée dans leur processus de développement, et indiqué que les attaquants avaient publié les paquets en dehors de la chaîne officielle de publication.
L’avis distingue les paquets Python touchés des images Docker officielles du proxy LiteLLM, qui, selon lui, ne contenaient pas ces versions. Le simple fait d’utiliser LiteLLM ne suffit donc pas à établir qu’un déploiement donné a installé les versions malveillantes. La version et l’historique d’installation comptent.
Le 30 mars, le projet a annoncé une version issue d’une chaîne de publication reconstruite et isolée, assortie de contrôles de sécurité supplémentaires. Cela décrit la réponse des responsables ; cela ne nous dit pas à quels documents de Mercor les attaquants ont accédé et ne permet pas de récupérer ce qui a déjà été copié.
Une attaque de la chaîne d’approvisionnement logicielle exploite la confiance accordée à un élément dont dépend un système. Son mode de livraison peut paraître parfaitement banal : un nom de paquet familier, une nouvelle version plausible et une installation automatisée. La mise à jour arrive dans le bon uniforme.
Pourquoi remplacer le paquet n’est qu’une partie du rétablissement
L’analyse de Datadog, publiée le 24 mars et mise à jour le 27 mars, décrit du code de vol d’identifiants dans les véritables paquets LiteLLM. La charge malveillante recherchait des secrets accessibles, comme des identifiants cloud et des clés SSH, et comprenait des mécanismes de persistance et d’exécution ultérieure.
Les deux versions différaient par leurs chemins d’exécution. Datadog a trouvé du code malveillant dans un module du proxy en version 1.82.7 ; la version 1.82.8 utilisait aussi un fichier de démarrage de Python, permettant son exécution au lancement de l’interpréteur après l’installation.
Ses recommandations vont au-delà de la désinstallation du paquet : déterminer quels environnements ont été exposés, révoquer les identifiants accessibles, examiner l’activité ultérieure et reconstruire si nécessaire les systèmes touchés à partir de sources fiables. Un attaquant qui a copié une clé valide peut conserver son accès après la disparition du paquet malveillant initial.
C’est l’équivalent numérique d’expulser un cambrioleur du couloir tout en lui laissant une clé de la porte d’entrée qui fonctionne. Ranger le couloir est bienvenu. La serrure mérite toujours qu’on s’en occupe.
La question dérangeante derrière le titre
La préoccupation plus générale porte sur l’étendue des accès qui s’accumulent autour des outils et des fournisseurs qui facilitent le développement de l’IA. Notre article sur les écosystèmes concurrents de programmation avec l’IA (en anglais) explore l’attrait de ces processus de plus en plus connectés. Chaque connexion utile mérite aussi une réponse claire sur ce à quoi elle est autorisée à accéder.
Pour les clients, les questions importantes concernent leurs propres projets : qu’est-ce qui était accessible, quelles preuves montrent que des éléments ont été emportés, quels identifiants ont été remplacés et qu’est-ce qui reste à examiner ? Un chiffre impressionnant en téraoctets ne peut pas y répondre.
L’incident de Mercor est déjà assez grave sans lui décerner le titre de « tout le manuel de l’industrie de l’IA, dérobé ». Il y a une intrusion confirmée, un butin allégué et une enquête qui a encore du travail. Le chat peut s’alarmer sans prétendre avoir lu le rapport d’investigation numérique.
Traduction française de l’article original en anglais du 2026-04-04. Traduction réalisée avec l’aide de l’IA le 2026-11-02 ; les références temporelles restent celles de l’original.
