Hugging Face a détecté une intrusion menée de bout en bout par un système d’agents IA autonomes. L’attaque a exploité la chaîne de traitement des datasets pour atteindre plusieurs environnements internes, avant d’être reconstruite à partir de plus de 17 000 événements. L’incident révèle aussi une difficulté inattendue pour les défenseurs, certains modèles commerciaux ayant refusé d’analyser les traces de l’attaque.
Un dataset utilisé comme porte d’entrée
Hugging Face a révélé le 16 juillet avoir subi une intrusion dans une partie de son infrastructure de production. La plateforme spécialisée dans l’hébergement de modèles et de datasets affirme que l’opération a été exécutée de bout en bout par un système d’agents IA autonomes, sans toutefois avoir identifié le modèle de langage utilisé par l’attaquant.
Le point d’entrée se trouvait dans la chaîne de traitement des données. Un dataset malveillant a exploité deux mécanismes capables d’exécuter du code, l’un lié au chargement distant de datasets et l’autre à une injection dans un modèle de configuration. L’attaquant a ainsi pris pied sur un worker chargé de traiter ces fichiers.
L’opération ne s’est pas arrêtée à cette première machine. Le système agentique a élevé ses privilèges jusqu’au niveau du nœud, récupéré des identifiants associés aux environnements cloud et Kubernetes, puis effectué des mouvements latéraux dans plusieurs clusters internes pendant un week-end. Hugging Face décrit des milliers d’actions distribuées entre des environnements temporaires et un dispositif de commande et de contrôle capable de se déplacer entre différents services publics.
Des données internes consultées, mais pas de modèles altérés
L’intrusion a permis un accès non autorisé à un nombre limité de datasets internes ainsi qu’à plusieurs identifiants utilisés par les services de Hugging Face. L’entreprise n’avait pas encore terminé son analyse concernant une éventuelle exposition de données appartenant à des clients ou partenaires au moment de sa publication.
Elle affirme en revanche n’avoir trouvé aucune preuve de modification des modèles, datasets ou Spaces accessibles au public. Les images de conteneurs et les paquets publiés ont également été contrôlés sans qu’une compromission de la chaîne logicielle soit identifiée.
Hugging Face a fermé les deux chemins d’exécution de code exploités pour l’accès initial, reconstruit les nœuds compromis et révoqué les identifiants concernés. La société a aussi engagé une rotation plus large de ses secrets et renforcé les contrôles d’admission dans ses clusters. Elle recommande par précaution aux utilisateurs de renouveler leurs jetons d’accès et d’examiner l’activité récente de leur compte.
Plus de 17 000 actions reconstituées par l’IA
La détection initiale est elle-même passée par un système utilisant des modèles de langage pour trier les événements de sécurité. Le rapprochement de plusieurs signaux inhabituels a permis d’identifier l’intrusion.
Hugging Face a ensuite utilisé des agents d’analyse pour examiner le journal des actions de l’attaquant, composé de plus de 17 000 événements. Ils ont servi à reconstruire la chronologie, retrouver les indicateurs de compromission, identifier les identifiants manipulés et séparer les actions réelles des leurres déposés par l’adversaire. Selon l’entreprise, ce travail a été réalisé en quelques heures plutôt qu’en plusieurs jours.
Cette automatisation ne transforme pas l’IA en arbitre autonome de l’enquête. Les agents ont surtout absorbé un volume d’actions devenu difficile à traiter manuellement au rythme de l’attaque, en laissant aux équipes la validation de l’impact et des mesures de réponse.
Les garde-fous bloquent l’analyse des défenseurs
L’enquête a fait apparaître une autre asymétrie. Hugging Face a d’abord tenté d’utiliser des modèles commerciaux accessibles par API pour analyser les commandes, les charges d’exploitation et les éléments de commande et de contrôle collectés. Les mécanismes de sécurité de ces services ont bloqué les requêtes, sans pouvoir distinguer une investigation légitime d’une tentative de produire ou d’améliorer une attaque.
L’entreprise s’est finalement tournée vers GLM 5.2, un modèle open weight exécuté sur sa propre infrastructure. Ce choix lui a permis de poursuivre l’analyse sans envoyer hors de son environnement les traces de l’attaquant ni les identifiants qu’elles contenaient. Hugging Face précise que cet épisode ne remet pas en cause le principe des garde-fous, mais montre leurs limites lorsqu’ils sont appliqués sans tenir compte du travail des équipes de réponse à incident.
L’incident documente surtout un nouveau déséquilibre opérationnel. L’attaquant pouvait automatiser librement des milliers d’actions, tandis que les défenseurs se sont heurtés aux restrictions des modèles accessibles par API. Pour reprendre l’avantage sans exposer leurs données d’enquête, ils ont dû disposer de leur propre capacité d’analyse.
