~7 minutes
Début juillet 2026, Hugging Face, le plus gros repository de modèles IA open-source au monde, a détecté un accès non autorisé sur son infrastructure de production. L’entreprise confirme la fuite de “datasets internes limités” et de plusieurs credentials, via un chargeur de code distant détourné et une injection de template dans la configuration des datasets.
Ce qui mérite qu’on s’arrête dessus, c’est la suite : l’attaque n’a pas été pilotée à la main, mais orchestrée par un agent IA autonome qui a enchaîné tout seul des milliers d’actions sur des sandboxes éphémères, un week-end entier.
Source : The Hacker News.
Ça fait un moment qu’on entend parler des agents IA offensifs, mais toujours au conditionnel : “un jour”, “bientôt”, une fois qu’on aurait fini de sécuriser le reste. Bon, ce jour est arrivé. L’agent en question a tourné tout un week-end sans s’arrêter, et il a abattu, sans jamais avoir besoin de dormir, ce qu’un red teamer met généralement plusieurs jours à faire. J’avoue que même en ayant écrit deux ou trois articles là-dessus ces derniers mois, ça me fait un petit quelque chose de le voir arriver en vrai plutôt qu’en hypothèse de threat model. Ça me rappelle un audit que j’ai mené il y a deux ans sur un pipeline MLOps client : on avait justement flaggé un trust_remote_code laissé à true par défaut sur un job de préprocessing, jugé “pas prioritaire” parce que personne n’imaginait qu’un attaquant automatisé irait le tester méthodiquement un week-end entier. Visiblement, quelqu’un l’a fait ailleurs.
Et ce n’est pas n’importe quelle boîte. Hugging Face n’a rien d’une PME avec un stagiaire DevOps qui a oublié de fermer un port un vendredi soir. C’est l’infrastructure sur laquelle des dizaines de milliers d’organisations tirent leurs modèles, leurs datasets, leurs pipelines d’inférence. Une brèche là-bas, ça touche directement la confiance que toute une industrie place dans ce dépôt, pas juste le bilan d’incident d’une seule entreprise.
Note du PandaRedacteur : le jour où un VP Sécurité me dira “on n’a pas besoin de threat modeler notre chaîne d’approvisionnement IA, on ne fait que télécharger des modèles”, je lui montrerai cet article. Télécharger n’est jamais un acte passif quand la chose téléchargée exécute du code, et ça fait quinze ans que je le répète à peu près sur toutes les chaînes de dépendances possibles.
L’entreprise n’a trouvé aucune preuve d’altération des modèles publics, des datasets ouverts, ni de la supply chain logicielle diffusée aux utilisateurs, ce qui est plutôt rassurant. Mais bon, ça ne dit rien de ce qui s’est passé côté infrastructure interne. Et là, on sait déjà que l’attaquant a mis la main sur des credentials cloud et progressé d’un cluster à l’autre ; reste à savoir jusqu’où exactement, et je doute qu’on ait toute l’histoire avant un moment.
Que s’est-il passé ?
A priori, deux failles distinctes, qui combinées ont donné à l’attaquant tout ce dont il avait besoin pour passer d’un accès applicatif à un accès infrastructure. Rien de franchement neuf individuellement, remarquez, c’est plutôt la combinaison qui pique.
Il y a d’abord un abus de chargeur de code distant (“remote code loader”) dans le pipeline de traitement des données, un composant censé charger dynamiquement du code lié au traitement d’un dataset, détourné pour exécuter n’importe quoi. Et il y a une injection de template dans la configuration des datasets, le classique cas où une chaîne censée décrire de simples métadonnées finit interprétée comme du code par le moteur de rendu qui la traite. On voit ce genre de faille depuis des années sur les moteurs de templating web ; rien de nouveau sous le soleil, sauf que là, c’est branché sur un repository que des dizaines de milliers d’organisations interrogent chaque jour, ce qui change pas mal l’échelle du problème.
flowchart LR
A["Dataset malveillant<br/>config avec template injecté"] --> B["Pipeline de traitement<br/>chargeur de code distant abusé"]
B --> C["Exécution de code<br/>sur sandbox éphémère"]
C --> D["Escalade vers accès node-level"]
D --> E["Collecte de credentials cloud"]
E --> F["Mouvement latéral<br/>plusieurs clusters, un week-end"]
F --> G["Milliers d'actions orchestrées<br/>par l'agent autonome"]
L’échelle et la vitesse d’exécution, voilà ce qui distingue cet incident d’une intrusion classique. J’ai fait suffisamment de red team pour savoir qu’un humain teste trois ou quatre hypothèses avant de lâcher l’affaire pour la nuit, quitte à revenir dessus le lendemain avec un œil neuf. L’agent, lui, n’a pas de lendemain, juste une boucle qui énumère, échoue, ajuste et recommence à une cadence qu’aucune équipe de détection calibrée sur un rythme humain n’anticipe. Les sandboxes éphémères, censées limiter le blast radius d’une exécution de code non fiable, sont devenues ici le terrain de jeu où l’agent a pu itérer sans jamais laisser une trace persistante facile à corréler.
Un sandbox éphémère protège contre la persistance de l’attaquant, pas contre sa patience. Et un agent, contrairement à un humain, a une patience infinie et un coût marginal quasi nul.
Analyse STRIDE de ce qui s’est passé
| Catégorie STRIDE | Applicable | Explication |
|---|---|---|
| Spoofing (Usurpation d'identité) | Oui | Les credentials cloud volés permettent à l'attaquant de se présenter comme un composant légitime de l'infrastructure sur les clusters atteints. |
| Tampering (Falsification) | Modéré | Aucune altération confirmée des modèles publics ou des datasets ouverts, mais l'accès node-level obtenu aurait techniquement permis une falsification interne. |
| Repudiation (Répudiation) | Oui | Des milliers d'actions automatisées sur des sandboxes éphémères compliquent fortement l'attribution et la reconstruction forensique précise de la chronologie. |
| Information Disclosure (Divulgation) | Oui | Datasets internes limités et plusieurs credentials confirmés comme exfiltrés ou exposés. |
| Denial of Service (Déni de service) | Faible | Rien dans les faits rapportés n'indique un objectif ou un impact de disponibilité ; l'attaque vise la collecte d'accès, pas la perturbation du service. |
| Elevation of Privilege (Élévation de privilèges) | Oui | C'est le cœur de la chaîne : d'une exécution de code en sandbox à un accès node-level, puis à des credentials cloud exploitables sur plusieurs clusters. |
Je mets Tampering en “Modéré” et pas en “Critique”, et ça mérite une justification parce que ça pourrait choquer : l’accès node-level obtenu aurait techniquement permis à l’attaquant de modifier des artefacts, mais rien dans les faits rapportés n’indique qu’il l’ait fait, et Hugging Face est justement le mieux placé pour le vérifier via ses hash de build. Je préfère rester factuel sur ce que l’entreprise a confirmé plutôt que de dramatiser un potentiel non exploité, quitte à revoir cette ligne si de nouvelles informations sortent.
Impact potentiel de cette faille
| Impact | Niveau | Description |
|---|---|---|
| Confidentialité | Critique | Datasets internes limités et credentials cloud exposés ; périmètre exact de la fuite encore en cours de qualification par Hugging Face. |
| Intégrité | Modéré | Aucune altération confirmée des modèles publics, datasets ouverts ou supply chain logicielle diffusée aux utilisateurs. |
| Disponibilité | Faible | Aucun impact rapporté sur la disponibilité du service ; l'attaque a été neutralisée sans interruption majeure signalée. |
| Réputation | Sévère | Hugging Face est un point de confiance central pour toute une industrie ; l'incident touche la crédibilité de l'ensemble de l'écosystème de distribution de modèles, pas uniquement l'entreprise elle-même. |
Ce qu’il vous reste à faire
Si c’était mon infra, je commencerais par une rotation immédiate de vos tokens d’accès Hugging Face, sans attendre une confirmation officielle que vous êtes concerné. Ne discutez pas, faites-le. Je m’occuperais ensuite des contrôles d’admission stricts sur tout pipeline qui charge dynamiquement du code ou interprète une configuration de dataset comme un template ; la faille racine ici, c’est une désérialisation non fiable comme on en croise depuis quinze ans ailleurs, rien de sorcier à colmater une fois qu’on sait où regarder.
N’accordez jamais à vos runtimes de traitement de données des credentials cloud à portée large ; un composant qui parse des métadonnées n’a strictement rien à faire avec les mêmes droits qu’un opérateur d’infrastructure, et pourtant c’est exactement ce genre de sur-permission qu’on retrouve à chaque post-mortem de ce type. Loggez et alertez sur les cadences d’action anormales, pas seulement sur des signatures connues, un agent autonome ne ressemble à aucune attaque “signée”, c’est le volume et la vitesse qui trahissent l’automatisation. Et traitez vos sandboxes d’exécution comme un périmètre de sécurité à part entière, avec leur propre isolation réseau, pas comme un simple filet de sécurité applicatif qu’on installe et qu’on oublie.
Ce type d’incident recoupe ce que je décrivais dans Non-Human Identities : vos agents IA ont déjà plus de credentials que vos humains. Le vecteur initial ici reste applicatif, mais au fond c’est la sur-permissivité des credentials du pipeline de traitement qui a transformé une simple exécution de code en compromission multi-clusters.
Si le sujet des agents offensifs autonomes vous semble encore théorique, allez lire RAMPART & Clarity : quand les outils rejoignent le threat modeling agentique. Les outils de défense commencent tout juste à raisonner à cette échelle-là. L’attaque, elle, y est déjà, et visiblement elle n’a pas attendu qu’on soit prêts.
Note du PandaRedacteur : Hugging Face précise aussi que ses modèles propriétaires refusaient d’analyser les artefacts d’attaque réels durant l’investigation forensique, pour des raisons de “contenu sensible”. J’adore l’ironie : construire un garde-fou contre les abus, puis découvrir qu’il vous empêche d’enquêter sur votre propre incident. Va falloir inventer un mode “j’ai un badge et un mandat” pour ces modèles-là, parce que là on marche sur la tête.