Vue normale

Il y a de nouveaux articles disponibles, cliquez pour rafraîchir la page.
À partir d’avant-hierTech Généraliste

« Bon sang, le lecteur a les droits admin ? » : OpenAI révèle le forum secret que ses agents ont créé avant de pirater Hugging Face

6 août 2026 à 14:30

Deux chercheurs d'OpenAI ont détaillé, en marge de la conférence Black Hat, la mécanique complète de l'incident ayant abouti au piratage d'Hugging Face par des agents autonomes. Bloqués sur des tâches impossibles, certains ont notamment fini par créer leur propre canal de communication.

Les IA d'OpenAI ont piraté Hugging Face pour tricher à un test

Par : Korben ✨
22 juillet 2026 à 09:55

Le pirate qui a mis à genoux la prod de Hugging Face voulait juste tricher à son examen, voilà ce qu'OpenAI a reconnu hier. Les agents qui se sont promenés durant tout un week-end dans les clusters de la plateforme, c'étaient leurs modèles à eux, GPT-5.6 Sol et un modèle pré-release encore plus balèze, fonctionnant en mode "refus cyber réduits à des fins d'évaluation".

Le point de départ c'est ExploitGym , contenant 898 vraies vulnérabilités piochées dans des programmes userspace, dans le moteur JavaScript V8 de Google et dans le noyau Linux. On colle l'agent devant un input qui fait planter un programme, et on regarde s'il arrive à en tirer un exploit qui marche.

Dans ce document de recherche sorti en mai, GPT-5.5 sortait 120 exploits fonctionnels, derrière les 157 de Claude Mythos Preview. Mais le modèle testé ce week-end là, lui, a trouvé un "raccourci". Comme l'explique OpenAI "toutes les preuves suggèrent que les modèles étaient hyperfocalisés sur la recherche d'une solution pour ExploitGym, allant à des extrêmes considérables pour atteindre un objectif de test plutôt étroit".

Pour saisir l'ampleur du raccourci, regardez la pièce dans laquelle ils étaient enfermés. C'est un environnement hautement isolé, avec un seul trou dans le mur, un accès réseau "*restreint à la possibilité d'installer des paquets via un logiciel tiers hébergé en interne qui fait office de proxy et de cache pour les registres de paquets *". En clair, le seul truc qui pouvait parler à l'extérieur, c'était le machin qui allait chercher les dépendances !

ExploitGym, le benchmark que les modèles cherchaient à résoudre. 898 vulnérabilités réelles, et les scores de GPT-5.5 et Claude Mythos Preview.

Et vous devinez la suite... Les modèles ont cramé une grosse quantité de tokens à chercher la sortie pour finalement la trouver dans ce proxy, sous la forme d'un zero-day que personne ne connaissait (la faille a depuis été signalée à l'éditeur). Le seul tuyau autorisé était donc LE point faible. Ensuite, escalade de privilèges et déplacement latéral de machine en machine, jusqu'à en atteindre une avec un accès Internet et voilà...

Une fois dehors, ils en ont alors déduit tout seuls que Hugging Face hébergeait probablement les modèles, les datasets et les solutions d'ExploitGym.

Donc direction huggingface.co, avec credentials volés et zero-days enchaînés jusqu'à décrocher une exécution de code à distance sur les serveurs, puis lecture des solutions du test directement dans la base de production. Aucune destruction, aucune demande de rançon. Juste les corrigés des tests comme des bacheliers qui emploient mal leur intelligence !

Petite précision qui compte, c'est bien l'équipe de Hugging Face qui a détecté et stoppé l'activité sur son infra, et qui avait déjà entamé le confinement et la reconstruction forensique avec ses propres modèles open source quand OpenAI l'a contactée. Je vous racontais l'histoire vue de leur côté il y a deux jours, relevant notamment que les modèles américains refusaient d'analyser leurs logs d'attaque.

C'est pas un peu de la science fiction tout ça ??? Maintenant si vous vous demandez ce que vous risquez en tant qu'utilisateur, sachez que côté public, rien n'a bougé sur les modèles, les datasets et les Spaces. L'incident a uniquement touché des datasets internes et des credentials de service et visiblement, rien n'a été altéré par les agents IA en vadrouille.

Côté mesures, OpenAI dit appliquer des contrôles stricts sur la configuration de son infra "au prix de la vélocité de recherche" pendant que les failles sont patchées, et a fait entrer Hugging Face dans son programme trusted access. Ce qui règle accessoirement le problème du refus que HF a rencontré lors de l'analyse des logs.

La veille de cette révélation, OpenAI publiait d'ailleurs un billet sur l'alignement des modèles à long horizon bourré d'anecdotes du même genre, avec un modèle qui contourne les restrictions de sa sandbox pour aller ouvrir une pull request sur GitHub alors qu'on lui demandait de poster sur Slack. Ou encore un autre qui, pour esquiver les détecteurs de secrets, a découpé le corps du token en deux fragments, les a obfusqués, puis a reconstruit le credential à l'exécution.

On dirait qu'ils n'avaient pas anticipé que ça aille aussi loin leurs petites expérimentations...

Après, OpenAI ne minimise pas et parle même d'un "incident cyber sans précédent, impliquant des capacités cyber à l'état de l'art". Ces modèles peuvent maintenant découvrir et exploiter des chemins d'attaque complètement inédits dans des systèmes en prod, sans avoir besoin d'un accès au code source. C'était théorique jusqu'à ce week-end.

Maintenant, si un modèle a lu les solutions dans la base de production, que valent encore les scores obtenus sur ExploitGym ? Ça on n'en sait rien.

Avant de sortir les violons, le contrepoint le plus juste que j'ai lu vient de Rich Mogull, analyste en chef de la Cloud Security Alliance qui explique que pour lui c'est un cas d'école en matière d'échec d'alignement, car le modèle n'était pas malveillant, il a fait précisément ce qu'on lui demandait, à savoir maximiser sa performance. Sauf qu'une fois les garde-fous retirés et assez de marge donnée, "résoudre le test" et "compromettre un tiers pour voler les réponses" sont devenus la même instruction.

Puis c'est aussi un problème de consentement, car un test de laboratoire qui se barre pour compromettre les systèmes en production, c'est quand même un risque qui est porté par quelqu'un qui n'a pas choisi de mener l'expérience. Alors bon, c'est tombé sur Hugging Face qui a géré ça comme un chef, mais ça aurait pu très bien tomber sur un hôpital.

Voilà les amis... On nous avait promis Skynet , on nous avait promis Matrix, et voilà que 15 ans plus tard, le vrai visage du soulèvement des machines c'est un putain de modèle qui passe son week-end à défoncer trois infrastructures d'affilée pour améliorer sa note à un contrôle.

Un ennemi qui vous hait, vous pouvez le raisonner ou lui envoyer Arnold Schwarzenegger. Mais un ennemi dont la seule mission c'est d'optimiser une métrique, vous ne pouvez que relire très attentivement le prompt que vous lui avez donné et croiser les doigts. La preuve quand une IA prend la première place du classement américain de HackerOne ou arrive à dénicher des milliers de zero-days pour Anthropic , c'est que l'instruction initiale ou le garde-fou était plus solide que ce que nous a pondu OpenAI ce week-end.

Source

Neural Drive - Le jeu de kart qui tourne sans moteur de jeu, dans votre navigateur

Par : Korben ✨
20 juillet 2026 à 15:41

Aujourd'hui je vais vous parler d'un jeu de karting façon Mario Kart qui fonctionne sans moteur 3D et sans même une seule ligne de code.

En réalité, il s'agit d'un modèle de 130 millions de paramètres qui est capable de deviner à quoi doit ressembler l'image suivante. Cela a été mis en ligne hier soir par Asankhaya Sharma, c'est le gars derrière OptiLLM . Ça s'appelle Neural Drive et ça imite Super Tux Kart , le Mario Kart libre dont je vous ai déjà parlé.

Neural Drive est donc un modèle qui regarde les sept dernières images ainsi que les touches que vous enfoncez sur votre clavier. Son job c'est simplement de peindre l'image suivante. Ainsi, si vous appuyez sur la flèche du haut, il dessinera une carte qui avance, si vous tournez à gauche, il dessinera un virage...etc.

Donc, il n'y a aucun code derrière, c'est juste une hallucination que vous pilotez en 384 x 192.

Les 262 Mo du fichier ONNX se téléchargent dans votre onglet et c'est votre carte graphique qui transpire ensuite, avec le WebGPU. Il y a donc zéro serveur derrière, exactement comme l'agent Gemma que je vous montrais en avril .

Je l'ai testé chez moi sur mon Mac Studio dans Firefox et je suis à 2,5 frames par seconde, ce qui représente 405 millisecondes de génération par image sur mon GPU Apple. Donc autant vous prévenir qu'à ce rythme-là c'est injouable. Vous appuyez sur une touche, le monde se redessine mollement, et vous conduisez comme dans un rêve où vos jambes ne répondent plus... Mais ça reste dingue quand même !

Sharma annonce que sur les MacBook M récents on peut obtenir environ 10 images par seconde, et sur des GPU ça devrait approcher le temps réel, 15 à 20 images par seconde. L'écart avec ma mesure vient sûrement du fait que je suis en train de compiler tout un tas de conneries au moment où j'écris cet article... donc testez plutôt que de me croire sur parole. Et si vous êtes sur mobile, les petits boutons sous l'écran servent de contrôles tactiles, si vous avez de la patience.

Aucune de ces images n'existe dans un fichier de jeu. Le chrono en haut à droite est illisible parce que le modèle le repeint à chaque frame.

Le plus marrant, c'est tout ce qu'il vous dessine en plus de la route. Il régénère aussi l'interface : le compteur de tours, la minimap en bas à gauche, les petites têtes de Tux empilées sur le côté, le chrono en haut à droite. Sauf qu'il ne sait pas ce qu'est un chrono. Du coup les chiffres bavent, se réécrivent tout seuls, vous annoncent un tour 1 sur 300 ! Ce modèle ne compte pas le temps écoulé, il peint simplement des pixels qui ressemblent à du temps. Et pendant ce temps-là le décor fond carrément en haut de l'image, avec des bouts de falaise qui coulent dans le ciel.

Côté cuisine, c'est un LatentDiT de 130,8 millions de paramètres (768 de dimension, 12 couches) posé sur un petit ConvVAE qui compresse l'image d'un facteur 8. Le gros du boulot d'optimisation c'est que le modèle d'origine avait besoin de 8 étapes de débruitage par image, et la version distillée n'en fait plus que 2. C'est ce qui vous fait passer de "démo qui rame" à "démo qui rame un peu moins". Vous démarrez à l'une des 18 positions pré-enregistrées dans un fichier de seeds, et si votre navigateur n'a pas WebGPU, ça bascule sur le CPU avec un message d'avertissement sans ambiguïté : "prêt (CPU, ce sera lent)".

Vous avez aussi les poids PyTorch, dont le checkpoint non distillé de 523 Mo, si l'envie vous prend de bidouiller l'entraînement. C'est la même famille d'idées que DIAMOND, l'IA qui rêve pour mieux jouer , ou que Mirage 2 , sauf qu'ici tout a été ramené à la taille d'une page web. Le kart ne pèse plus que 262 Mo et tient dans un onglet de navigateur !

Bref, c'est une démo, pas un jeu. Mais c'est la première fois que je fais tourner un monde entier chez moi sans envoyer un seul octet à un serveur.

Ça se teste ici , et les poids sont là .

Hugging Face piraté, les IA américaines refusent de les aider

Par : Korben ✨
20 juillet 2026 à 08:50

Hugging Face vient de raconter sur son site comment son infra de production s'est fait défoncer par un essaim d'agents IA autonomes. Le point de départ, c'est un dataset piégé déposé sur la plateforme qui exploitait deux chemins d'exécution de code dans le pipeline qui traite les datasets. Ajoutez à ça un loader qui accepte du code distant et une injection de template dans une config, et hop, on obtient du code qui tourne sur un worker maison.

À partir de là, l'attaquant est monté en accès node-level, a ramassé des credentials cloud et cluster, puis s'est promené latéralement dans plusieurs clusters internes. Le tout durant tout un week-end, tranquillou ! Hugging Face parle de "plusieurs milliers d'actions individuelles à travers un essaim de sandboxes éphémères, avec un command-and-control auto-migrant hébergé sur des services publics". Et en plus, ils ne savent toujours pas quel modèle pilotait le truc !

Ce qui a été touché, c'est donc un ensemble limité de datasets internes et plusieurs credentials utilisés par leurs services. Côté public, rien n'a bougé sur les modèles, les datasets et les Spaces, et leur supply chain logicielle est saine. Nuance importante quand même, ils disent n'avoir trouvé aucune trace d'altération, pas que rien n'a été altéré. Ils cherchent encore si des données partenaires ou clients ont morflé. Les concernés seront prévenus directement.

La divulgation publiée par Hugging Face le 16 juillet 2026.

Pour analyser les logs de l'attaque, Hugging Face a d'abord fait ce que vous auriez fait, c'est-à-dire envoyer tout ça à des modèles frontier derrière des API commerciales. Refus ! Les garde-fous se déclenchaient sur les vraies commandes d'attaque, les payloads d'exploit et les artefacts de command-and-control, sans savoir faire la différence entre un attaquant et une équipe de réponse à incident.

Du coup ils se sont rabattus sur GLM 5.2, le modèle open-weight de Z.ai, tournant sur leur propre infra. C'est celui dont je vous parlais fin juin , le premier modèle open source qui m'a vraiment convaincu.

Et voici leur conclusion : "*Nous ne savons pas quel modèle alimentait les agents de l'attaquant, un modèle hébergé jailbreaké ou un open-weight sans restrictions. Dans les deux cas, l'attaquant n'était contraint par aucune politique d'usage, alors que notre propre travail forensique était bloqué par les garde-fous des modèles hébergés que nous avions essayés en premier. *"

La leçon qu'ils en tirent, c'est d'avoir un modèle capable comme GLM 5.2, validé, et prêt à tourner sur sa propre infra avant l'incident. Ça évite le blocage par garde-fous d'OpenAI ou Anthropic et surtout ça évite que les données de l'attaquant et vos credentials partent se balader chez un tiers.

Le versant moins déprimant, c'est que l'IA a aussi bossé côté défense. Leur détection d'anomalies fait du triage LLM sur la télémétrie pour séparer le vrai signal du bruit quotidien, et des agents d'analyse ont reconstitué toute la timeline à partir de plus de 17 000 événements enregistrés. En heures, là où ça prendrait des jours à la main.

Côté ménage, ils ont surtout viré le point d'ancrage de l'attaquant, reconstruit les nœuds compromis, révoqué et tourné les credentials et tokens concernés avec une rotation plus large des secrets par précaution, déployé des garde-fous et des contrôles d'admission plus stricts sur les clusters, et amélioré la détection pour alerter les équipes en quelques minutes, 24h/24. Maintenant, si vous avez un compte là-bas, ils vous recommandent de faire tourner vos tokens d'accès et de jeter un œil à l'activité récente.

Ce genre d'histoire commence à devenir une vraie série... j'en parlais avec GitLost où un seul mot glissé au bon endroit suffisait parfois à faire cracher ses dépôts privés à l'IA de GitHub.

Bref, allez renouveler vos tokens Hugging Face et si votre pipeline exécute du code venu d'ailleurs, c'est le moment de regarder ça de plus près.


Mise à jour du 22 juillet 2026 : on connaît le coupable, et ce n'est pas un pirate. OpenAI a publié sa version des faits le 21 juillet, et l'essaim d'agents qui a défoncé l'infra de Hugging Face, c'était ses propres modèles. GPT-5.6 Sol, celui-là même qui a effacé le Mac de Matt Shumer et une base de prod , accompagné d'un modèle pre-release encore plus costaud, tous avec les refus cyber volontairement réduits pour les besoins d'une évaluation interne.

Et le mobile vaut le détour. Ces modèles planchaient sur ExploitGym, un benchmark qui mesure justement leur capacité à dénicher et enchaîner des failles. Coincés dans leur bac à sable, ils ont cramé une quantité considérable de compute à chercher la sortie, ont trouvé un zero-day dans le logiciel tiers qu'OpenAI héberge en interne comme proxy et cache de registres de paquets (faille depuis divulguée à l'éditeur), puis ont escaladé les privilèges de machine en machine jusqu'à en atteindre une avec un accès Internet. Et là, ils en ont déduit tout seuls que les solutions du benchmark devaient traîner quelque part chez Hugging Face. Credentials volés, zero-days enchaînés, exécution de code à distance sur les serveurs : tout ça, c'était juste le chemin le plus court pour tricher à l'examen.

L'ironie devient franchement indécente quand on empile les couches. Hugging Face s'est fait démonter par des modèles américains aux garde-fous retirés, pendant que d'autres modèles américains lui refusaient l'analyse de ses propres logs. OpenAI le dit noir sur blanc : "Ces protections de déploiement n'étaient intentionnellement pas activées pendant cette évaluation, parce qu'elle visait à tester les vulnérabilités cyber." Depuis, Hugging Face a été intégré au programme trusted access d'OpenAI, ce qui règle accessoirement le problème du refus. Et Clem Delangue en tire la leçon qui va bien : "Cet incident, peut-être le premier du genre, prouve un point auquel nous croyons depuis longtemps : la sécurité de l'IA ne sera pas résolue par une seule entreprise travaillant en secret. Elle sera résolue au grand jour, de manière collaborative, avec un large accès à l'IA pour chaque défenseur, partout."

À noter quand même, c'est bien l'équipe de Hugging Face qui a détecté et stoppé l'activité, et qui avait déjà entamé le confinement et la reconstruction forensique avec ses propres modèles open source quand OpenAI l'a contactée. Au moment où j'écris ces lignes, leur billet du 16 juillet n'a d'ailleurs pas bougé d'un pouce et dit toujours ignorer quel LLM pilotait le truc. Et la veille de cette révélation, OpenAI publiait un billet sur un modèle interne qui, lui, a passé une heure à chercher une faille dans sa sandbox pour aller ouvrir une pull request sur GitHub alors qu'on lui avait demandé de poster ses résultats sur Slack. Deux évasions, deux billets, deux jours.

Source

Moebius - Effacer un objet d'une photo depuis votre navigateur

Par : Korben ✨
12 juillet 2026 à 05:55

Simon Willison, le créateur de Datasette et co-créateur de Django, vient de porter un modèle d'inpainting d'image directement dans le navigateur. Sa démo vous permet de choisir une photo, de peindre sur la zone à faire disparaître et ensuite le modèle IA reconstitue ce qu'il manque. Et ce qui est merveilleux avec cette appli c'est que tout tourne sur votre carte graphique en local, comme ça vos données restent chez vous.

Le modèle s'appelle Moebius, dispose de 0,22 milliard de paramètres, et a été développé par une équipe de l'université Huazhong en Chine. À l'origine c'est un modèle PyTorch, que Willison a converti au format ONNX pour le faire tourner via ONNX Runtime Web sur le backend WebGPU, une nouvelle API qui donne aux pages web un accès direct au GPU. Et ce qu'on obtient, c'est un modèle de diffusion qui s'exécute à 100% côté client dans Chrome ou Safari.

Lors de la première utilisation, l'outil télécharge 1,27 Go de poids depuis Hugging Face, ce qui est énorme pour une page web. Mais c'est un one-shot car ensuite, le navigateur range tout ça dans son Cache Storage, et les fois d'après il ne re-télécharge rien.

Je l'ai installé et testé et ça fonctionne vraiment très très bien. J'ai sélectionné quelques tuiles comme un bourrin et ça me les a enlevées très proprement en quelques dizaines de secondes (une fois le modèle initial téléchargé évidemment).

C'est du vrai inpainting génératif en tout cas et pas un truc qui recopie les pixels d'à côté.

Willison raconte dans le README que la conversion PyTorch vers ONNX et l'appli web complète ont été réalisées par Claude Code avec le modèle Claude Opus 4.8, et qu'il n'a "*pas regardé une seule ligne de code *". Il s'est juste contenté de tester dans le navigateur et de signaler ce qui clochait. Hé ouais c'est comme ça maintenant, les temps changent ;)

C'est open source sous licence Apache 2.0, la démo est en ligne, et le code est sur GitHub si vous voulez le lancer chez vous. Testez, et effacez ce gars avec son coup de soleil sur le crâne qui gâche votre plus belle photo de vacances, je ne vous juge pas ^^.

Source : Hackaday

❌
❌