Microsoft Authenticator divulgue vos codes de connexion à cause d’un bug critique

Une faille de sécurité dans Microsoft Authenticator peut laisser fuiter des codes à usage unique ou des liens de connexion vers une application malveillante déjà présente sur ton téléphone. Le problème touche iOS et Android, et il est identifié sous le nom CVE-2026-26123. Dans le scénario défavorable, l’attaquant récupère les informations nécessaires pour tenter de se connecter à ta place.

La bonne nouvelle, c’est que le correctif est déjà intégré dans les versions actuelles de l’application, donc l’action la plus efficace est simple, mettre à jour tout de suite. La mauvaise, c’est que la faille s’appuie sur un réflexe courant, cliquer sur un lien de connexion, scanner un QR code, puis choisir par erreur la mauvaise appli pour “ouvrir” l’action. Et là, tu viens de donner la main à la mauvaise porte.

CVE-2026-26123 touche Microsoft Authenticator sur iOS et Android

Le cur du problème, c’est une fuite possible de données d’authentification depuis Microsoft Authenticator vers une autre application installée sur le même appareil. La vulnérabilité CVE-2026-26123 concerne les mécanismes utilisés pour gérer des codes temporaires et des liens de connexion qui ouvrent directement une étape de login. Sur le papier, ce sont des fonctions pratiques, sur le terrain, elles deviennent sensibles si une appli malveillante réussit à intercepter le flux.

Concrètement, l’attaque ne tombe pas du ciel. Il faut déjà qu’une application malveillante soit installée sur ton téléphone. Ensuite, il faut que tu lui “donnes” l’occasion de traiter une action de connexion, par exemple en appuyant sur un lien de connexion reçu dans un mail, ou en validant une ouverture d’application après un scan de QR code. Tu vois le piège, tu penses juste te connecter, mais tu choisis le mauvais “gestionnaire”.

Les deep links, ce sont des liens construits pour ouvrir une app à un endroit précis, pas juste la page d’accueil. Dans le monde de l’authentification, ils servent à accélérer les parcours, tu cliques, l’app s’ouvre, tu valides, terminé. Le souci, c’est que si le système laisse une autre appli se déclarer capable de gérer ce type de lien, et que tu la sélectionnes par erreur, tu risques de lui transmettre des éléments de connexion.

Dans un usage pro, le risque augmente avec les téléphones personnels utilisés pour le travail, le fameux BYOD. Beaucoup d’entreprises reposent sur l’authentification multifacteur via une app, parce que c’est plus robuste qu’un simple mot de passe. Mais un téléphone BYOD, c’est aussi un téléphone où l’on installe des apps de tous horizons. Et c’est précisément la condition d’exploitation décrite, une appli malveillante déjà là, prête à se glisser dans le parcours.

Le scénario d’attaque passe par une appli malveillante déjà installée

Le scénario est presque banal, tu reçois une demande de connexion, tu cliques, ton téléphone te demande avec quelle application ouvrir l’action, et tu choisis trop vite. Dans ce cas, l’appli malveillante peut récupérer le code à usage unique ou les informations contenues dans le lien d’authentification. Et ce n’est pas une théorie de labo, c’est l’intérêt même de ce type de bug, détourner une interaction inter-apps pour aspirer ce qui ne devrait jamais sortir.

Pour comprendre l’impact, imagine un compte Microsoft personnel ou un compte pro, protégé par MFA. Normalement, même si un mot de passe fuit, il manque la deuxième étape. Là, si l’attaquant obtient le code temporaire ou un lien de connexion utilisable, il peut tenter de franchir la barrière. Tout dépend du contexte, du timing, et de la façon dont le service valide la session, mais l’objectif est clair, contourner la protection en capturant l’élément “éphémère”.

Il y a une nuance importante, cette faille ne signifie pas que n’importe qui peut te pirater à distance sans action de ta part. Il faut une application malveillante sur l’appareil et une erreur de manipulation, ce qui réduit la surface d’attaque par rapport à une vulnérabilité exploitable en un clic depuis le web. Mais ne te rassure pas trop vite, parce que ce prérequis colle très bien à la réalité, beaucoup de gens installent des apps sans vérifier l’éditeur, surtout hors contexte professionnel.

Dans les équipes sécurité, on voit souvent ce type de chaîne, un téléphone déjà “sale”, puis une étape d’authentification interceptée. Un admin que j’appellerai Marc, responsable SecOps dans une PME, résume le problème en une phrase, “si tu as déjà une appli toxique, le MFA devient ton dernier rempart, donc la moindre fuite à ce moment-là, c’est la porte ouverte”. Le ton est direct, mais l’idée est juste, la deuxième étape doit rester hermétique.

Les deep links et QR codes accélèrent la connexion, mais ouvrent un angle mort

Les deep links ont été pensés pour fluidifier l’usage, un clic et tu arrives au bon endroit. Dans la vie quotidienne, c’est devenu la norme, banque, messagerie, outils pro. Pour l’authentification, c’est pareil, un lien peut ouvrir Microsoft Authenticator et déclencher une validation. Le problème, c’est que ce confort repose sur une mécanique d’association, quelle appli a le droit de gérer quel type de lien.

Le risque décrit ici, c’est l’erreur de sélection du gestionnaire de lien. Sur mobile, tu as déjà vu ce pop-up, “ouvrir avec…”, parfois avec une option “toujours”. Si une appli malveillante se positionne pour apparaître dans cette liste, et que tu la choisis, elle peut recevoir ce que tu voulais envoyer à l’app légitime. Dans le cas de l’authentification, ça peut inclure un OTP ou un jeton temporaire, bref, de quoi tenter une connexion.

Les QR codes ajoutent une couche de complexité. On les utilise pour connecter un compte sur un nouveau navigateur ou valider un accès. Tu scannes, tu confirmes, c’est rapide. Mais dans ce type de flux web-vers-app, la question “quelle appli traite l’action” revient. Si tu n’es pas attentif, tu peux valider un enchaînement où l’appli qui reçoit l’information n’est pas celle que tu crois. C’est rarement visible, parce que tout se passe en quelques secondes.

Et là, petite critique, les interfaces mobiles ne t’aident pas toujours. Les noms d’apps se ressemblent, les icônes peuvent être trompeuses, et l’utilisateur est pressé. On a construit des parcours où la sécurité dépend d’une micro-décision sur un écran, alors que le but initial du MFA était de réduire la dépendance aux comportements parfaits. De ce fait, la mise à jour est indispensable, mais il faut aussi reprendre de bonnes habitudes, vérifier l’app qui ouvre l’action.

La mise à jour corrige la faille, Microsoft recommande d’installer la dernière version

La mesure la plus efficace est nette, mets à jour Microsoft Authenticator vers la version la plus récente disponible sur ton store. Le correctif pour CVE-2026-26123 est déjà intégré dans les versions actuelles, donc l’objectif est d’arriver sur un build corrigé. Sur la plupart des téléphones, les mises à jour automatiques existent, mais elles ne sont pas toujours activées, ou elles peuvent être retardées par des réglages d’économie de données.

Si tu gères un parc mobile en entreprise, c’est le moment d’être carré, vérifier l’état de mise à jour sur les appareils gérés, pousser l’update, relancer les retardataires. Les organisations qui autorisent le BYOD ont un défi supplémentaire, elles ne contrôlent pas tout. Mais elles peuvent au moins communiquer clairement, imposer un niveau minimal de version, et rappeler une règle simple, ne pas installer d’apps inconnues qui demandent à gérer des liens de connexion.

Si tu ne peux pas mettre à jour immédiatement, il reste une mitigation comportementale, éviter d’installer de nouvelles applications, et faire très attention quand tu cliques sur un lien de connexion ou quand tu scannes un QR code. Vérifie que le gestionnaire sélectionné est bien Microsoft Authenticator ou une application de confiance. Ça paraît évident, mais dans la vraie vie, c’est exactement le moment où on va trop vite, surtout quand on essaie juste d’accéder à une boîte mail ou à un outil pro.

Dans les cas où l’app se comporte mal, codes qui n’arrivent pas, boucle de connexion, options bloquées, Microsoft met en avant des solutions de contournement côté utilisateur, comme choisir “se connecter autrement” ou “je ne peux pas utiliser mon application”, puis utiliser un canal de secours si disponible. Et côté entreprise, un admin peut forcer une réinscription MFA. Ce n’est pas directement lié à la faille, mais c’est utile, parce que certains vont paniquer et casser leur accès en bricolant.

Les entreprises doivent durcir les usages MFA sur les téléphones personnels

Cette affaire rappelle une réalité, le MFA est solide, mais il n’est pas magique. Si le téléphone est compromis, ou si des flux inter-apps sont fragiles, la deuxième étape peut être contournée. Pour les entreprises, le sujet est brûlant, beaucoup de services critiques reposent sur un smartphone personnel. Le risque n’est pas seulement la compromission d’un compte, c’est l’accès à des outils internes, à des environnements de production, ou à des consoles d’administration.

Dans une approche pragmatique, il faut réduire la probabilité du prérequis, une appli malveillante déjà installée. Ça passe par des politiques d’installation, des listes d’apps autorisées, ou au minimum une sensibilisation régulière. Dans les structures équipées, des solutions MDM peuvent vérifier l’état de conformité. Et pour les équipes IT, il faut un plan d’action clair, patcher vite, communiquer, puis vérifier. Le temps est un facteur, parce qu’une vulnérabilité publique attire toujours des tentatives opportunistes.

Il faut aussi revoir les parcours de connexion. Quand un service propose plusieurs méthodes, code temporaire, notification push, lien profond, QR code, il faut comprendre ce qui est le plus robuste face à une interception locale. Une règle simple, privilégier les mécanismes qui minimisent l’exposition de secrets réutilisables. Et ne pas oublier les comptes à haut privilège, administrateurs, finance, RH. Ce sont eux qui font le plus de dégâts en cas d’accès frauduleux, même si l’attaque ne touche qu’un seul téléphone.

Dernier point, la communication aux utilisateurs. Un message interne utile, c’est du concret, “mets à jour aujourd’hui”, “ne choisis pas une appli inconnue pour ouvrir un lien de connexion”, “si tu vois une option ‘toujours’, ne l’active pas sans vérifier”. Marc, le même responsable SecOps, me disait récemment qu’il préfère une consigne imparfaite mais appliquée, plutôt qu’une page de procédure que personne ne lit. C’est un peu brutal, mais sur mobile, ça marche souvent mieux.