Un seul paramètre non documenté a suffi pour transformer Muse de Meta en porte dérobée de dictée

Le 21 septembre 2026, le chercheur en sécurité Patrick Wardle a publié une preuve de concept appelée not-a-mused montrant qu'une préférence non documentée au sein de l'assistant Muse de Meta pour macOS détermine où l'application envoie ce que vous dictez. La clé est endo_voyager_dictation_endpoint, et tout processus s'exécutant sous l'utilisateur connecté peut la réécrire sans mot de passe administrateur ni invite macOS. Faites-la pointer vers une adresse contrôlée par l'attaquant, et l'audio et la transcription de Muse partent là-bas au lieu d'aller à Meta ; Wardle a montré qu'un attaquant peut alors lire la dictée, injecter des instructions auxquelles Muse obéit et récupérer un jeton qui permet de se connecter au compte Muse de l'utilisateur — atteignant chaque appareil où ce compte est connecté. Meta affirme avoir déployé un correctif à chaud le lendemain. Aucune attaque réelle n'a été signalée. Le propre compte rendu de la divulgation par l'archive, avec sa notation de gravité et ses sources citées, figure dans l'archive des incidents d'IA aux côtés des autres entrées de vulnérabilité d'agents de cette série.

Ce que fait le paramètre, et pourquoi une seule clé a suffi

Wardle est cofondateur de l'organisation à but non lucratif Objective-See, rapporte The Register. Muse est l'agent personnel de Meta, lancé aux États-Unis plus tôt en septembre 2026, et The Hacker News rapporte qu'une fois qu'un utilisateur l'active, il peut agir sur ses fichiers, ses e-mails, ses messages, son calendrier, ses applications d'achat et de maison connectée, en utilisant tous les accès que la personne choisit de lui donner. La découverte de Wardle ne figure pas dans cette liste d'accès. Elle se situe dans les rouages sous-jacents : l'application Mac inclut un paramètre qui achemine l'audio de dictée hors de l'appareil, et l'adresse vers laquelle il est acheminé est stockée là où le système d'exploitation ne la protège pas contre d'autres programmes s'exécutant sous le même utilisateur.

Selon les propres termes du dépôt, la preuve de concept démontre qu'« un attaquant local ou un logiciel malveillant peut modifier ce point de terminaison sans privilèges particuliers », après quoi « des invites dictées peuvent être envoyées vers un point de terminaison contrôlé par l'attaquant ». Le dépôt énumère ce que cela permet potentiellement : la capture de l'audio et des invites dictés, l'injection d'invites dans Muse, le vol du matériel d'authentification de Muse, et l'abus de tout accès que l'utilisateur a accordé à l'application. Il résume la conséquence en une ligne : « L'accès de Muse peut potentiellement devenir l'accès de l'attaquant. » La preuve de concept met en œuvre ce que son README appelle un sous-ensemble des plus de 50 commandes que Muse expose.

La séquence décrite par The Hacker News est mécanique. Un programme que l’attaquant exécute sur le même Mac réécrit la préférence, puis attend. L’utilisateur touche le microphone et parle. L’audio et le texte résultant parviennent au programme de l’attaquant plutôt qu’à Meta. Depuis cette position, Wardle a démontré trois choses : lire ce que l’utilisateur a dicté, ajouter des instructions supplémentaires auxquelles Muse fait confiance et qu’elle applique — le média décrit l’effet comme une injection de prompt — et capturer le jeton qui permet de se connecter au compte Muse de l’utilisateur.

Un jeton, et chaque appareil derrière lui

Le jeton est la partie qui quitte le Mac. The Hacker News rapporte que Muse envoie son jeton d’authentification avec la dictée redirigée, de sorte que le même écouteur qui capture la transcription capture aussi l’identifiant. Avec celui-ci, selon Wardle, un attaquant peut lire l’historique de conversations du compte et donner directement des ordres à l’assistant — et comme un compte Muse peut être connecté sur plusieurs appareils, ces ordres ne se limitent pas à la machine compromise.

Wardle a exécuté cette partie sur son propre matériel. Depuis le Mac, il a demandé à l’application Muse sur son iPhone de signaler sa position exacte, d’effectuer une analyse Bluetooth des appareils à proximité et de dresser la liste des commandes de maison connectée qu’elle pouvait envoyer. The Hacker News ajoute une limite à la démonstration : lors de ses tests, l’assistant se contentait de rédiger des messages au lieu de les envoyer de lui-même.

C’est l’argument pour considérer ce bug comme bien plus qu’une simple fuite de dictée. The Register rapporte la façon dont Wardle présente le problème général — à savoir que macOS a été conçu pour empêcher un programme de lire les données d’un autre, et qu’un agent auquel un accès étendu a été accordé devient un point de défaillance unique pour ces contrôles. « Ce n’est pas parce qu’un mauvais voisin emménage que ce voisin a automatiquement accès à tous les appartements », a-t-il déclaré à The Register. Un assistant à qui l’on a remis les clés, c’est une autre histoire.

Ce qu’il ne fait pas

Trois limites sont énoncées dans les sources et importent pour quiconque évalue l’exposition. Premièrement, la faille ne permet pas à elle seule de pénétrer dans un Mac : elle nécessite du code déjà en cours d’exécution sous l’utilisateur connecté, ce qui explique pourquoi le dépôt de Wardle la qualifie d’« attaque locale » et que Meta l’a ensuite qualifiée d’élévation de privilèges locale. Deuxièmement, elle ne contourne pas l’isolation des applications macOS — The Hacker News rapporte qu’elle ne franchit pas la frontière qui empêche une application de lire les mots de passe et jetons enregistrés d’une autre ; le propre jeton de Muse accompagne la dictée redirigée, et l’attaque fonctionne en amenant Muse à agir avec des accès qu’il possède déjà. Troisièmement, elle ne démontre pas que la conception cloud de Meta, que l’entreprise a conçue pour isoler l’agent de chaque utilisateur des autres, ait été compromise.

Ce que cela montre, en revanche, c’est pourquoi la sécurité des points de terminaison pourrait ne pas le remarquer. The Hacker News rapporte le point de Wardle selon lequel les commandes proviennent de Muse, une application signée normale, plutôt que de quelque chose qui ressemble à un logiciel malveillant ; The Register consigne la même préoccupation dans ses mots, à savoir qu’un produit EDR ne peut pas déterminer si une commande provient de l’utilisateur, de l’agent ou d’un attaquant.

Wardle attribue également une cause. The Register rapporte qu’Apple propose la dictée sur l’appareil et que, selon son évaluation, la vulnérabilité n’existerait pas si Meta avait utilisé cette API ; il suggère que Meta a choisi de ne pas le faire parce que l’entreprise veut les données, et ajoute : « Je pense qu’une partie de leur avidité pour les données utilisateurs ouvre en quelque sorte la porte, élargit la surface d’attaque. » Il s’agit de son inférence concernant les motivations de Meta, et non d’un fait documenté, et Meta n’y a pas répondu dans les articles examinés ici.

Divulgation, le correctif et une dispute à propos de l’étiquette

Wardle a rendu l’affaire publique sans prévenir Meta au préalable. The Hacker News rapporte qu’il a choisi la divulgation complète afin que les utilisateurs comprennent le risque et parce que c’est souvent la voie la plus rapide vers un correctif. The Register, qui l’a interrogé, indique que Meta n’a pas immédiatement répondu à sa demande de commentaire.

La réponse est arrivée le lendemain, accompagnée d’une caractérisation. Dans une publication sur les réseaux sociaux du 22 septembre, David Singleton, de Meta Superintelligence Labs, a déclaré que l’application Muse avait été révisée : « Il s’agissait d’une attaque par élévation de privilèges locale, et non d’un exploit distant. L’utiliser pour nuire nécessite donc du code malveillant déjà en cours d’exécution sur la machine de l’utilisateur sous son compte utilisateur, et le risque pratique pour les utilisateurs de l’application Muse pour Mac était donc assez faible. » La publication ajoutait : « Néanmoins, nous avons publié un correctif urgent pour l’application afin de résoudre le problème. »

Sur un point précis, les deux parties sont en désaccord, et ce désaccord porte sur la classification plutôt que sur le mécanisme. L’affirmation de Singleton repose sur l’exigence d’un code local existant. Wardle a déclaré à The Hacker News qu’un attaquant distant pourrait néanmoins y parvenir au moyen d’une astuce ClickFix — le schéma qui persuade un utilisateur de coller une seule commande dans Terminal, sans rien à télécharger ni à installer — ce qui fournirait l’exécution locale dont l’exploit a besoin. Aucune source consultée pour cet article ne rapporte que quelqu’un l’a réellement fait, et la voie ClickFix est une possibilité démontrée plutôt qu’une campagne observée.

Ce que le correctif modifie n’est pas public. The Hacker News a rapporté qu’il n’avait pas pu confirmer ce que fait la modification et que Meta n’avait pas publié d’avis de sécurité ; le dossier de l’archive note de même qu’aucun avis n’a été émis. Un utilisateur de Muse dispose donc de la parole de Meta selon laquelle le problème est traité, et d’aucun document décrivant comment.

Ce qui est établi, et ce qui ne l’est pas

L’archive attribue à cette fiche la note de confiance A — bien documentée, avec des sources primaires concordantes — et ne la signale pas comme contestée. Cette notation ne signifie pas qu’un préjudice a eu lieu : la fiche marque le préjudice réel comme faux, et rien dans la couverture examinée ne décrit un utilisateur attaqué, un compte volé ou un fichier perdu. Les éléments de preuve sont une preuve de concept d’un chercheur, ses propres démonstrations et une déclaration d’un fournisseur.

• Établi : l’application Muse pour macOS comportait une préférence non documentée nommée endo_voyager_dictation_endpoint qui contrôlait l’endroit où la dictée était envoyée, et un processus s’exécutant sous l’utilisateur connecté pouvait la réécrire sans droits élevés, selon le dépôt de Wardle et les deux médias.

• Établi : la redirection de ce point de terminaison envoyait l’audio de dictée et la transcription à une adresse contrôlée par un attaquant, et le jeton d’authentification de Muse l’accompagnait, selon The Hacker News.

• Établi : un jeton obtenu de cette manière pourrait piloter Muse sur d'autres appareils connectés au même compte ; Wardle a démontré la remontée de la localisation, une analyse Bluetooth et une liste de commandes domotiques sur son propre iPhone, selon The Hacker News.

• Établi : l'attaque nécessitait une exécution de code en tant qu'utilisateur, n'a pas contourné l'isolation des applications de macOS et n'a pas compromis le cloisonnement cloud de Meta, selon The Hacker News et le dépôt de Wardle.

• Établi : Wardle a divulgué sans prévenir Meta au préalable, et Meta a déclaré le 22 septembre avoir publié un correctif d’urgence, selon The Register et The Hacker News.

• Non établi : ce que le correctif a modifié, si la préférence existe toujours dans les versions actuelles et si le chemin ClickFix y survit. Aucun avis, journal des modifications ni entrée CVE décrivant le correctif n'apparaît dans la couverture examinée.

• Non établi :si quelqu'un a été ciblé en conditions réelles, et si la faille était atteignable sur une plateforme autre que l'application macOS. Toutes les démonstrations consignées ont été réalisées sur les propres machines de Wardle.

• Non établi : reproduction indépendante. Les deux médias ont rapporté la découverte, et The Register a interrogé Wardle par téléphone, mais aucun tiers n'a publié son propre test de la redirection, et Meta n'a pas décrit la faille dans ses propres mots au-delà de la classification de Singleton.

Les conseils provisoires, et ce qui se généralise

Alors que le correctif n’était pas confirmé, The Hacker News a publié une courte liste de précautions à l’intention des utilisateurs de Mac, et il vaut la peine de la consigner parce qu’elle cartographie précisément l’exposition. Quittez ou supprimez Muse, ce qui ferme entièrement le chemin d’attaque. Passez en revue les applications et les autorisations dont dispose Muse et révoquez tout ce dont il n’a pas besoin, afin qu’un agent détourné hérite de moins de privilèges. Considérez le compte Muse et les comptes qui y sont liés comme exposés si le Mac est susceptible d’être déjà compromis, et changez ces mots de passe. Évitez la saisie vocale de Muse, qui est le déclencheur précis attendu par la preuve de concept. Et n’exécutez pas de commandes qu’un site web ou un message vous demande de coller dans Terminal, car c’est ainsi que commence le chemin d’attaque ClickFix.

Le constat transposable est plus étroit que « l’IA est peu sûre » et plus incisif que « corrigez vos applications ». L’utilité d’un agent et son rayon d’impact sont un seul et même nombre : les autorisations qui permettent à Muse de lire des fichiers et d’envoyer des messages sont celles qu’un attaquant hérite en le pilotant, et aucun des contrôles qu’il a franchis n’a lui-même été mis en échec. macOS a maintenu sa frontière applicative, le cloud de Meta a maintenu sa séparation, et le jeton n’a pas été extrait d’un trousseau de clés. Une préférence qui aurait dû être inerte jouait un rôle déterminant, et elle se trouvait en dehors de toutes les couches conçues pour protéger les données qu’elle visait. Le résumé du compromis de conception que Wardle a lui-même confié à The Register est celui qui survivra au correctif : « Ils sont super pratiques et donnent beaucoup de pouvoir. Mais ils ont tellement d’accès si vous les configurez pour qu’ils soient utiles. Ils pourraient pratiquement tout faire sur votre ordinateur. »