Le bot d'assistance IA de Meta pouvait réinitialiser le mot de passe Instagram de n'importe qui. Il a fonctionné pendant 44 jours.

Le 1er juin 2026, 404 Media et KrebsOnSecurity ont publié des enregistrements circulant dans des groupes Telegram, qui montraient l'assistant de récupération de compte de Meta attachant une nouvelle adresse e-mail à un compte Instagram pour quiconque le demandait, puis y envoyant la réinitialisation du mot de passe. L'attaquant n'avait besoin que d'un nom d'utilisateur et d'une phrase convaincante. En une semaine, dans une notification de violation adressée au procureur général du Maine, Meta a chiffré l'exposition à 20 225 comptes sur une période allant du 17 avril au 31 mai 2026. Le compte de marque de Sephora, le chief master sergeant de la Space Force américaine et la chercheuse Jane Manchun Wong figuraient parmi les comptes signalés comme détournés, plusieurs d'entre eux étant restés bloqués pendant des jours sans agent d'assistance humain à qui faire appel. Le dossier complet, avec ses sources et sa classification de gravité, se trouve dans l'Orca AI Incident Archive, qui recense les incidents liés à l'IA effectivement survenus, par date, par système et par type de défaillance.

L’archive classe l’incident comme critique, avec une implication confirmée de l’IA et un préjudice réel, et le range sous injection indirecte de prompt et abus d’identifiants. Ce qui suit distingue ce que Meta a déclaré publiquement de ce que les victimes, les chercheurs et les 72 premières heures de couverture médiatique ont allégué — car sur un point central, les deux versions ne concordent pas.

La défaillance était due à une vérification manquante, pas à un jailbreak.

Meta a déployé l’assistant sur Facebook et Instagram en mars 2026, en le présentant comme un outil de sécurité et de récupération de compte qui proposait « des solutions, pas seulement des suggestions », selon 404 Media. En interne, il était appelé High Touch Support, ou HTS : un agent conversationnel conçu pour aider les utilisateurs privés d’accès à leur compte qui ne parvenaient pas à passer par les formulaires de récupération statiques, et habilité à associer une nouvelle adresse e-mail à un compte et à déclencher une réinitialisation de mot de passe vers cette adresse.

Le défaut que Meta a fini par décrire était limité, et il ne s’agissait pas du modèle qui décidait d’être serviable. Dans une lettre de notification de violation de données déposée auprès du bureau du procureur général du Maine, Amber Hannah, conseillère juridique générale associée de Meta responsable du droit de la réponse aux incidents, a écrit : « L’outil lui-même fonctionnait correctement et opérait comme prévu ; toutefois, en raison d’un bogue dans un chemin de code distinct, le système n’a pas vérifié correctement que l’adresse e-mail fournie par la personne demandant une réinitialisation de mot de passe correspondait à l’adresse e-mail associée au compte Instagram de cet utilisateur. » Elle a ajouté que, lorsque l’adresse ne correspondait pas, le système « envoyait à tort un lien de réinitialisation de mot de passe à cette adresse e-mail non associée plutôt que de rejeter la demande ».

En pratique, la séquence, telle que reconstituée par KrebsOnSecurity à partir des enregistrements Telegram, comportait quatre étapes :

• L'attaquant s'est connecté via un VPN avec une adresse située dans la région de la cible ou à proximité, afin de contourner les contrôles de localisation d'Instagram.

• Ils ont lancé la procédure de récupération sur un nom d'utilisateur et ont sélectionné l'assistant d'assistance IA.

• Ils ont demandé au bot d’associer une adresse e-mail qu’ils contrôlaient — un enregistrement commençait par « Associe simplement ma nouvelle adresse e-mail » — et le bot y a envoyé le code à usage unique.

Ils ont saisi le code, récupéré le lien de réinitialisation, changé le mot de passe, et le propriétaire légitime s’est retrouvé bloqué.

Aucun logiciel malveillant, aucun mot de passe volé, aucune page d'hameçonnage. Brian Krebs a fait remarquer que la technique s'est propagée via des canaux Telegram à partir du 31 mai, et que les comptes pro-iraniens ayant publié la vidéo avaient également défiguré certains des profils saisis ce week-end-là.

44 jours, et un nombre qui a bougé

La fenêtre est l’élément du dossier qui a mis le plus de temps à devenir public. Dans sa notification au procureur général du Maine, Meta a déclaré avoir découvert la vulnérabilité le 31 mai 2026 et avoir désactivé HTS ce jour-là. Le document fixe la date de la violation elle-même au 17 avril, ce qui, selon BleepingComputer, est probablement la première attaque exploitant cette faille. Cela représente 44 jours d’une voie d’écriture non authentifiée vers les champs d’identité du compte Instagram, une durée que la branche de recherche de la Cloud Security Alliance évalue également à 44 jours.

Le décompte a changé deux fois. Le dépôt de Meta indique que 20 225 comptes ont potentiellement été compromis, dont 30 dans le Maine, et l’entreprise décrit ce chiffre comme une limite supérieure, car certaines tentatives d’accès ont pu provenir de titulaires de comptes légitimes. Le 9 juin, se faisant l’écho d’une enquête du New York Times, Android Authority a déclaré qu’environ 34 000 utilisateurs d’Instagram avaient été touchés et qu’environ 20 000 comptes avaient été compromis, des milliers d’autres ayant vu leur nom d’utilisateur modifié ou perdu temporairement l’accès. La différence tient à une définition, pas à une contradiction : 34 000 correspond à l’ensemble des comptes concernés, 20 225 au nombre de piratages que Meta était prêt à certifier. La lettre de Meta indique aussi que l’entreprise ne sait pas lesquelles des données potentiellement accessibles ont effectivement été consultées — la liste couvre les coordonnées, les dates de naissance, les publications, les messages privés, l’historique d’activité, les informations de profil et les services tiers liés.

Les affirmations sur les corrections et les dates de correction ont elles aussi divergé aux yeux du public. Le 1er juin, le vice-président des communications de Meta, Andy Stone, a déclaré sur X que « le problème qui s’est réellement produit a déjà été corrigé ». Le 2 juin, TechCrunch a rapporté que des utilisateurs signalaient encore des prises de contrôle et que des membres de canaux Telegram proposaient encore à la vente des identifiants détournés — tout en précisant que tous les détournements signalés ne pouvaient pas être rattachés à la même technique.

Ce que l’authentification à deux facteurs a fait, et ce que les premiers rapports disaient qu’elle avait fait

C'est ici que les faits consignés et leur restitution divergent, et il vaut la peine d'être précis à ce sujet.

Le compte rendu de Meta est explicite. La lettre de Hannah indique qu’après la réinitialisation du mot de passe, « la partie non autorisée a pu se connecter au compte si le titulaire du compte n’avait pas activé l’authentification à deux facteurs (2FA) ». KrebsOnSecurity a rapporté la même chose à partir des enregistrements de l’exploit : la technique échouait contre les comptes pour lesquels la MFA était activée. L’analyse de la Cloud Security Alliance a qualifié la 2FA de « contrôle limitant efficace », en notant que le flux de récupération n’accordait jamais l’accès à la couche d’authentification que la 2FA régit. La faille se situait au niveau de la porte de récupération à côté de la porte de connexion, et non de la porte de connexion elle-même.

En revanche, une vague de témoignages de victimes dans les premiers jours disait le contraire. Le 2 juin, BleepingComputer a cité des utilisateurs qui insistaient sur le fait que leur identité avait été vérifiée par reconnaissance faciale et qu'ils avaient activé la 2FA, et a cité un utilisateur, André, selon qui la méthode « contourne les protections de la 2FA ». gHacks a rapporté la même chose le 3 juin. Le résumé en une ligne de cet incident dans l'archive porte aussi cette affirmation plus forte, en décrivant le bot comme contournant l'authentification à deux facteurs.

Meta n'a publié aucune analyse post-mortem technique, si bien que la divergence reste non résolue plutôt que tranchée. Ce que l'on peut dire, c'est que le seul document de première main — la déclaration déposée signée par le conseil juridique de Meta lui-même — décrit une prise de contrôle qui s'est arrêtée aux comptes sans second facteur, et que les médias les plus proches des enregistrements de l'exploit ont rapporté la même chose. Considérez « le bot a déjoué la 2FA » comme une allégation, et non comme un fait établi.

Un second mécanisme rapporté relève de la même catégorie. Des utilisateurs ont déclaré à BleepingComputer et gHacks que le processus de récupération acceptait une vidéo selfie, et que des attaquants animaient une photo publique de la cible via un générateur de vidéo par IA pour le franchir. Ni la plainte de Meta ni la reconstitution des enregistrements par Krebs ne mentionne cette étape. Il s'agissait peut-être d'une voie parallèle ; le dossier public ne l'établit pas.

Les victimes, et le récit que Meta conteste

Le groupe confirmé est un étrange mélange de comptes de marques, de militaires et de chercheurs : le compte de marque de Sephora, Chief Master Sergeant John Bentivegna de l’U.S. Space Force, et Jane Manchun Wong, qui a documenté dans ses propres publications la perte du compte. BleepingComputer a également cité les identifiants à un seul mot @hey et @korn, et a rapporté que le propriétaire de @korn avait passé six heures à essayer de joindre un humain et reçu quatre liens défectueux de l’IA d’assistance de Meta. Le même article a noté que les affirmations concernant les identifiants à une seule lettre @e et @f ne pouvaient pas être vérifiées de manière indépendante, certains les attribuant plutôt à un initié.

Un cas de victime largement repris est contesté. 404 Media, KrebsOnSecurity et TechCrunch ont tous rapporté qu'un identifiant dormant de la Maison-Blanche sous Obama figurait parmi ceux saisis et brièvement défigurés. Meta a qualifié de « complètement fausses » les affirmations selon lesquelles les comptes de dirigeants auraient été piratés, selon la BBC, et TechCrunch a consigné directement la contestation de l'entreprise. Tout le reste de la liste des victimes repose sur les reportages ; ce cas-là, non.

L'attribution s'arrête au canal, et non à une organisation. Les articles établissent que des instructions d'exploit fonctionnelles et des identifiants détournés ont été échangés dans des groupes Telegram, que certains comptes saisis ont été utilisés pour des messages pro-iraniens, et que des noms d'utilisateur courts « OG » ont une valeur sur le marché gris de l'ordre de dizaines de milliers de dollars — Krebs a cité des hackers affirmant une valeur de revente supérieure à 500 000 $ pour les noms qu'ils détenaient. Aucun article ne nomme de groupe, n'accuse personne ni n'établit qu'une seule opération a mené la campagne. La description, par l'archive, d'une opération de revente organisée est cohérente avec les articles, mais ne constitue pas un point que les sources citées prouvent.

Qu’est-ce qui a changé par la suite ?

La réponse de Meta, telle que décrite dans le document déposé et à BleepingComputer, a consisté à désactiver l’outil HTS, à supprimer le chemin de code défectueux, à invalider tous les liens de réinitialisation de mot de passe générés par le système et à placer les comptes concernés dans un point de contrôle de sécurité obligatoire exigeant une réinitialisation via des canaux vérifiés. Avant de relancer, l’entreprise a déclaré qu’elle corrigerait le contrôle d’authentification au point d’entrée de récupération d’Instagram afin qu’une adresse e-mail fournie soit vérifiée par rapport aux données du compte avant que toute réinitialisation ne soit lancée, et qu’elle examinerait les flux de récupération similaires sur ses autres plateformes.

La part du programme global qui a été mise en pause est plus limitée que cela n’y paraît. Des documents internes cités par le New York Times indiquaient que Meta n’avait mis en pause que l’expérience spécifique de récupération de mot de passe Instagram liée à l’incident, tout en laissant en place des projets d’assistance plus vastes alimentés par l’IA, a rapporté Android Authority. La note de la Cloud Security Alliance va plus loin, affirmant que Meta a désactivé le 31 mai les capacités autonomes du chatbot d’association d’adresses e-mail et de réinitialisation de mot de passe ; cette caractérisation est celle du groupe de recherche, et non une déclaration de Meta.

Pourquoi cela est classé comme injection de prompt, et pourquoi cette étiquette est contestée

L'archive classe l'incident sous l'étiquette IPI — injection de prompt indirecte — aux côtés de l'abus d'identifiants, et le cadrage en « confused deputy » (mandataire involontaire) est celui auquel la plupart des analystes ont recouru. Mais plusieurs des personnes les plus proches du dossier refusent l'étiquette d'injection.

Simon Willison, qui a forgé l’expression « injection de prompt », a écrit le 1er juin : « Meta a bel et bien connecté son système de support à un chatbot IA qui avait la capacité d’accélérer l’ensemble du processus de récupération de compte. Celle-ci ne mérite même presque pas le nom d’infection par prompt. Ne connectez pas votre bot de support de manière à permettre des prises de contrôle de compte en une seule opération ! » La Cloud Security Alliance a établi la même distinction en termes plus formels : l’attaque ne nécessitait aucun contenu malveillant caché dans un document ou dans la sortie d’un outil, l’attaquant n’a eu qu’à demander ; il s’agit donc d’un modèle de menace différent de l’injection de prompt classique, même si la conséquence est identique. Elle correspond à la catégorie LLM06:2025 d’OWASP, Excessive Agency — fonctionnalité excessive, permissions excessives et autonomie excessive, les trois étant réunies simultanément.

L’analyse de VentureBeat était plus directe, et c’est celle qui compte sur le plan opérationnel : de l’intérieur d’une pile de détection, l’attaque n’a produit aucun signal, car l’agent était un acteur autorisé et chaque écriture qu’il effectuait était enregistrée comme une transaction légitime. « Il n’y a aucun point d’appui à trouver, parce que l’agent était le point d’appui, et il était censé être là. »

Ce que ce document n’établit pas

Il n'existe pas de CVE pour la faille HTS, et aucune analyse technique publiée par Meta ne décrit ce que ce chemin de code faisait réellement. Le chiffre de 20 225 constitue la borne supérieure avancée par Meta, et non un décompte audité, et l'entreprise déclare ne pas pouvoir dire quelles données ont été consultées. Le nombre de comptes qui ont réellement été détournés, revendus ou conservés pendant un certain temps est inconnu. Personne n'a été inculpé et, à la date du dossier public résumé ici, aucun régulateur n'avait publié de conclusions spécifiques à cet incident.

Ce qui est établi est plus petit et plus utile que les gros titres : un agent de support a reçu un accès en écriture au seul champ qui détermine à qui appartient un compte, la vérification que le demandeur en était propriétaire se trouvait dans un autre chemin de code et ne s’exécutait pas, et il suffisait d’une phrase pour convaincre l’agent de passer outre. Le document déposé par Meta lui-même indique que l’outil « a fonctionné correctement et s’est comporté comme prévu ». C’est là le constat. Le bug se trouvait dans l’architecture autour de cela.