Cascades effectuées par des professionnels

La publication de plusieurs rapports techniques sur l’incident ayant conduit des agents IA d’OpenAI à attaquer Hugging Face permet aujourd’hui de mieux comprendre ce qui s’est passé. La chronologie est surprenante et pointe vers de nombreuses défaillances internes, mais le marketing continue de battre son plein.

Le 22 juillet, on apprenait que l’attaque enregistrée par Hugging Face contre ses infrastructures provenait en réalité d’OpenAI. Celle-ci n’avait pas choisi de s’en prendre à l’hébergeur de modèles IA : la faute en revenait à des agents qui étaient sortis de leur cadre de test pour atteindre plus rapidement les objectifs qui leur avaient été fixés, en l’occurrence la résolution des épreuves posées par le benchmark de cybersécurité ExploitGym.

• L’attaque contre Hugging Face est venue… d’OpenAI

Le 26 août, deux rapports beaucoup plus complets sont cependant apparus. Le premier vient d’OpenAI (PDF) et est une analyse technique fouillée des évènements. L’autre (PDF) de l’organisme à but non lucratif METR (Model Evaluation and Threat Research), mandaté par OpenAI comme expert indépendant et assisté d’un chercheur de Redwood Research. La chronologie semble digne d’un scénario de science-fiction au premier abord.

Des signaux dès mai 2026

Les premiers couacs sont apparus environ deux mois avant l’attaque contre Hugging Face, selon le rapport technique d’OpenAI. Le 8 mai, un agent de l’entreprise s’est retrouvé bloqué sur une tâche rendue volontairement impossible : accéder à des liens vers Google Drive depuis un environnement dépourvu d’accès internet.

L’agent ne se démonte pas pour autant et cible Artifactory, le gestionnaire de paquets utilisé en interne par OpenAI pour donner à ses agents un accès contrôlé aux dépendances de développement. L’agent attaque le logiciel au moyen d’une faille SSRF (server-side request forgery), mais échoue dans sa mise en pratique. Le processus laisse une scorie : un fichier écrit par l’agent dans Artifactory.

Le 12 mai, toujours dans le cadre d’un test, un deuxième agent trouve le fichier et conclut qu’il peut laisser par ce biais des messages à l’attention d’autres agents qui seraient susceptibles de disposer des ressources manquantes. Le lendemain, un troisième agent – disposant cette fois d’un accès internet – trouve ces notes et commence à s’en servir. Dans les jours qui suivent, un nombre croissant d’agents se met à utiliser ces fichiers comme un « message board » pour échanger sur les problèmes à résoudre.

Le 26 mai, plusieurs agents utilisent une faille SSRF pour obtenir un accès internet, cette fois avec succès. Ils découvrent six jetons d’authentification Hugging Face (qui avaient été exposés publiquement) et les partagent sur Artifactory, au bénéfice des autres agents. Un dépôt est même créé sur Hugging Face, ainsi qu’une application de relais dans le service Space.

Cet incident a finalement été découvert par OpenAI, mais n’a pas été rapporté aux responsables de détection et réponse aux incidents. Dans son rapport, l’entreprise avoue un défaut de communication.

L’escalade vers Hugging Face

Un mois plus tard, le 26 juin, OpenAI lance un test sur plusieurs agents, dans l’objectif de leur faire obtenir le meilleur score au benchmark ExploitGym. Les conditions sont cette fois connues, car c’est le processus qui aboutira à l’attaque contre Hugging Face en juillet. Pour rappel, OpenAI testait à ce moment deux modèles : GPT-5.6 Sol (leur modèle commercial le plus avancé actuellement) et un modèle interne, sans nom officiel, mais que METR nomme HPIM (« highly-persistent internal model ») dans son rapport.

Entre le 26 juin et le 4 juillet, les actions s’enchainent. Les agents ont d’abord découvert une faille dans un point de terminaison d’Artifactory servant au rafraichissement des jetons d’authentification et s’en sont servi pour obtenir des droits administrateur. Ces derniers ont été utilisés pour installer des plug-ins dans Artifactory, avec à la clé des capacités persistantes d’exécution de commandes. Dans l’intervalle, une alerte remonte le 27 juin pour signaler un comportement imprévu, mais n’est pas jugée bloquante. L’activité est alors devenue assez intense sur le serveur pour provoquer l’indisponibilité d’Artifactory le 6 juillet, déclenchant en interne un incident de sécurité. OpenAI dit alors avoir coupé le service compromis, révoqué les accréditations des agents et reconstruit une nouvelle instance d’Artifactory le même jour, effaçant l’ensemble des messages échangés par les agents.

Apple a envoyé un e-mail aux développeurs tiers pour les avertir d’un changement : « Nous vous contactons pour vous informer que les apps universelles pour macOS proposées sur le Mac App Store et nécessitant macOS 13 ou une version ultérieure peuvent désormais abandonner la prise en charge des Mac à processeur Intel ».

Cette prise en charge était obligatoire pour toute application publiée sur le Mac App Store, mais ne l’était bien sûr pas pour celles distribuées autrement. Le passage à l’architecture Arm remontant aujourd’hui à six ans avec la puce M1, le signal est clair : il est temps de passer à autre chose.

Apple vante d’ailleurs les avantages d’un tel abandon. En ciblant uniquement « arm64 » dans les réglages de compilation de l’application, le développement n’en sera que plus simple. En outre, plus besoin de passer par des binaires universels embarquant toutes les données pour les deux architectures (x86_64 et arm64). L’application s’en retrouvera d’autant allégée. Reste une condition : elle doit viser macOS 13 au moins.

Il n’y a bien sûr pas d’obligation à suivre ce conseil, les développeurs pouvant toujours compiler pour Intel s’ils le souhaitent. Comme l’indiquent nos confrères de MacG, macOS 27 et son Xcode correspondant ne pourront s’installer que sur des Mac Apple Silicon, plantant un nouveau clou dans le cercueil. macOS 27, alias Golden Gate, sera également la dernière version à prendre en charge la couche d’émulation Rosetta 2. 2027 sonnera définitivement le glas de l’architecture Intel chez Apple.

L'IA à la sauce Mozilla

Mozilla vient de publier de nouvelles versions de son navigateur pour l’ensemble des plateformes. Certaines contiennent des nouveautés importantes, particulièrement sur ordinateur et iOS.

Nouvelle mouture pour le navigateur de Mozilla, avec comme principale nouveauté la disponibilité de la Smart Window pour l’ensemble des utilisateurs en France, au Canada et aux États-Unis. En français, elle prend d’ailleurs officiellement le nom de « Fenêtre intelligente ».

Cette fonction est toujours en bêta et reste optionnelle. On y accède par le bouton Firefox situé en haut à droite de la fenêtre, près du menu hamburger (trois traits). Son utilisation réclame un compte Firefox, ce mode de navigation permettant ensuite de résumer des pages, comparer plusieurs onglets, retrouver des informations dans des onglets ou l’historique, obtenir des recommandations et ainsi de suite. Une fois la fonction activée, on peut choisir de toujours lancer Firefox dans ce mode.

Notez que la prise en charge de l’historique ne se fait qu’au sein de cette fenêtre intelligente. En outre, les conversations et « souvenirs » sont stockés localement, mais les requêtes transitent par les serveurs de Mozilla puis éventuellement vers d’autres, selon le modèle utilisé. Par défaut, Mistral Small 4 est recommandé. On peut également choisir entre Gemini 3.1 Flash Lite, Qwen 3 235B ou un autre LLM, à condition de fournir le point de terminaison et la clé API (ou jeton d’authentification).

Firefox 155 améliore dans la foulée cette fonction. Mozilla ajoute par exemple sous la fenêtre de conversation des boutons pour retourner rapidement dans des recherches précédentes. Les recherches passant par Exa sont également décrites comme beaucoup plus rapides, et la fonction d’organisation intelligente des onglets se veut plus pertinente. Rappelons que Firefox propose un réglage pour désactiver toutes les fonctions IA.

Parmi les autres nouveautés, on peut citer un nouveau compteur de traqueurs bloqués apparaissant au début de la barre d’adresse. Les conteneurs, « apparus » avec Firefox 153, peuvent maintenant être réorganisés, l’ordre choisi apparaissant ensuite partout où cette liste est affichée. Firefox 155 corrige en outre de nombreux bugs, dont un gênant qui pouvait empêcher une machine sous Linux d’entrer en veille après une longue session de navigation. Enfin, la version colmate une trentaine de failles de sécurité, dont 13 de dangerosité élevée.

Firefox pour iOS a désormais son Ad Blocker

Aux côtés de cette version pour ordinateurs, Firefox pour iOS a lui aussi du neuf. Mozilla a annoncé très officiellement ce 1ᵉʳ septembre l’intégration d’un bloqueur de publicité, nommé Ad Blocker. Il est construit sur la base de l’API d’Apple pour bloquer les contenus et la liste de filtrage EasyList. Une technique qui n’est pas neuve, Vivaldi proposant une fonction équivalente.

Ce blocage publicitaire n’est pas activé par défaut. Il faut se rendre dans les réglages puis dans la partie Navigation. Dans son billet, Mozilla prévient que l’efficacité de sa fonction n’est pas garantie : « Le bloqueur de publicités ne bloquera pas toutes les annonces. Les publicités diffusées directement par le site que vous visitez et les annonces affichées dans les résultats de recherche apparaîtront toujours ». En outre, les raccourcis et autres contenus sponsorisés affichés par Firefox ne sont pas pris en charge, mais peuvent être désactivés via un réglage séparé.

Ce bloqueur de publicités est une fonction supplémentaire et peut donc fonctionner de concert avec la protection améliorée contre le suivi qui, elle, s’occupe de bloquer les traqueurs.

Mozilla en profite pour lancer une pique à Apple dans un billet séparé (en lien dans l’annonce) : il serait temps que l’entreprise propose une véritable architecture pour les extensions de navigateur. Safari en propose, mais leur récupération passe par l’App Store. Rien d’équivalent n’est prévu pour les autres, Mozilla fustigeant au passage (une nouvelle fois) l’obligation d’utiliser WebKit comme moteur de rendu. Sur Android, rien de tout cela : Firefox utilise son moteur Gecko et prend en charge les extensions depuis longtemps.