Un contournement d’authentification par rejeu laisse 22 000 serveurs Exchange exposés

11 août 2026. Microsoft divulgue CVE-2026-62911, un contournement d’authentification par rejeu dans Exchange Server, noté CVSS 8.0. 28 août 2026. L’office allemand BSI évalue à environ 85 % la part des serveurs Exchange sur site non corrigés en Allemagne, soit près de 5 100 machines. 31 août 2026. Shadowserver recense 21 899 adresses IP Exchange exposées sur Internet. Pourquoi c’est important : le correctif existe depuis trois semaines, un PoC public circule, et une part entière du parc — les serveurs Exchange 2016 sans contrat ESU — n’a tout simplement pas de chemin de mise à jour.

La mécanique : rejouer une authentification capturée

La vulnérabilité relève du CWE-294, « contournement d’authentification par rejeu de capture ». Concrètement, un attaquant qui dispose déjà d’un accès limité au serveur peut capturer un échange d’authentification légitime, puis le rejouer pour se faire passer pour un utilisateur plus privilégié. Le vecteur CVSS 3.1 le décrit sans ambiguïté : réseau, complexité d’attaque faible, privilèges requis faibles, interaction utilisateur requise, et impact élevé sur la confidentialité, l’intégrité et la disponibilité.

La nuance « interaction utilisateur requise » compte. Le rejeu suppose qu’une victime s’authentifie par un chemin que l’attaquant peut observer ou orienter — typiquement un relais de type NTLM, où l’attaquant se place en intermédiaire entre un client et le serveur. L’élévation de privilèges qui en découle transforme un accès de base en compromission de la messagerie : lecture de boîtes aux lettres, exfiltration de courriels, et un point d’ancrage au cœur de l’annuaire d’entreprise.

Le correctif est publié depuis le 11 août 2026, via KB5121574 pour Exchange Server 2019 CU15 et KB5121575 pour Exchange Server 2019 CU14. Les branches antérieures et Exchange Server 2016 CU23 sont également concernées, mais leur cas de figure diffère — on y revient.

Un maillon de la chaîne Pwn2Own Berlin

CVE-2026-62911 n’est pas une découverte isolée. Elle faisait partie de la chaîne de démonstration présentée par Orange Tsai et DEVCORE lors de Pwn2Own Berlin 2026, la compétition de piratage où les chercheurs vendent des exploits à des conditions contrôlées. Le fait que cette faille serve de maillon dans une chaîne complète en dit long : à elle seule, elle élève des privilèges ; combinée à d’autres, elle participe à une compromission de bout en bout.

Cette origine a deux conséquences. D’abord, la qualité de l’analyse : une faille démontrée en conditions réelles par des chercheurs reconnus n’est pas un avis spéculatif. Ensuite, la diffusion du savoir : après la compétition, les détails techniques ont commencé à circuler, et un PoC public a été signalé sur GitHub. La fenêtre entre « correctif disponible » et « exploitation largement accessible » s’est refermée en quelques jours.

22 000 serveurs exposés, un PoC public

Les chiffres donnent la mesure de l’inertie. Au 31 août 2026, Shadowserver identifiait 21 899 adresses IP Exchange exposées ou non corrigées sur Internet. Le BSI allemand, qui notifie directement les opérateurs réseau depuis le 14 août 2026, estimait au 28 août qu’environ 85 % des installations Exchange sur site du pays — soit 5 100 serveurs — n’avaient toujours pas appliqué la mise à jour. Le NCSC néerlandais a confirmé qu’un exploit fonctionnel circulait.

Ce décalage n’est pas une curiosité. Un serveur de messagerie exposé est une cible de choix : il concentre des identifiants, des données sensibles et un accès privilégié à l’annuaire. La combinaison d’un PoC public, d’une surface exposée qui se compte en dizaines de milliers d’adresses et d’une correction retardée reproduit le scénario classique des campagnes ProxyLogon et ProxyShell de 2021, où l’exploitation massive a suivi la publication des détails techniques.

Détecter une authentification rejouée

La bonne nouvelle pour les défenseurs est que le rejeu n’est pas furtif par nature. Une authentification rejouée laisse la même signature qu’un relais NTLM classique : un compte privilégié qui s’authentifie depuis une source inhabituelle, ou une session établie sans la connexion interactive correspondante. Surveillez les journaux d’événements qui montrent une boîte aux lettres consultée par un compte dont l’authentification provient d’une machine d’où il ne se connecte jamais, et croisez avec les pistes d’audit msExch d’accès non-propriétaire.

La boucle de détection est simple. Activez la journalisation d’audit des boîtes aux lettres pour les accès non-propriétaire, alertez sur tout compte administratif dont la boîte est ouverte par un délégué, et traitez toute authentification NTLM qui transite par un chemin où elle n’a rien à faire — un endpoint exposé, un service sensible au relais — comme un candidat au rejeu. Les organisations qui ont déjà remplacé NTLM par Kerberos sont nettement moins exposées à cette classe de faille, ce qui en fait la mitigation la plus forte au-delà du correctif.

Le piège Exchange 2016 : une population qui ne peut plus patcher

Le point le plus structurel n’est pas la faille, mais le cycle de vie. Exchange Server 2016 a atteint sa fin de support en octobre 2025. Depuis, les mises à jour de sécurité post-support dépendent d’une éligibilité aux Extended Security Updates (ESU) — un contrat payant que toutes les organisations n’ont pas souscrit. Résultat : une organisation encore sur Exchange 2016 sans couverture ESU ne peut pas « appliquer le correctif » ; elle doit soit s’inscrire aux ESU, soit migrer.

C’est précisément ce qui rend CVE-2026-62911 plus dangereuse que son score ne le suggère. Une part non négligeable du parc exposé n’a pas de chemin de mise à jour trivial. Le BSI notifie directement les opérateurs, signe que les canaux d’avis classiques ne suffisent plus à faire bouger la population concernée. Pour une organisation soumise à NIS2, l’exposition d’une infrastructure de messagerie non corrigée et non supportée engage en outre la responsabilité au titre de la gestion des vulnérabilités.

Corriger, ou migrer

La première action dépend de votre branche. Si vous êtes sur Exchange Server 2019, appliquez KB5121574 (CU15) ou KB5121575 (CU14) sans attendre : le correctif est publié, le PoC est public, et l’exploitation active est plausible. Vérifiez ensuite les journaux d’authentification pour détecter d’éventuels rejeux antérieurs — une élévation réussie laisse rarement le serveur intact.

Si vous êtes sur Exchange Server 2016, la question n’est pas le patch. Évaluez immédiatement votre éligibilité ESU : si elle est valide, souscrivez et appliquez la mise à jour ; sinon, le seul chemin de réduction du risque est la migration vers une branche supportée ou vers un service managé. En attendant, réduisez la surface : retirez l’exposition Internet directe, restreignez l’accès par VPN ou par passerelle, et durcissez les protocoles d’authentification pour limiter le rejeu.

Au-delà du correctif ponctuel, la leçon porte sur le cycle de vie. Une faille de messagerie n’attend pas la fin du support pour être exploitée. Les décisions de migration prises des années plus tôt se paient, au moment d’un incident, en jours de fenêtre ouverte.

Verdict

Si vous êtes sur Exchange 2019, corrigez aujourd’hui avec KB5121574 ou KB5121575 : le PoC est public, la fenêtre d’exploitation est ouverte, et une élévation par rejeu ne laisse aucune trace de chiffrement à casser.

Si vous êtes sur Exchange 2016 sans ESU, ne cherchez pas de patch : il n’y en a pas. Souscrivez aux ESU si vous y êtes éligible, sinon lancez la migration vers une branche supportée, et coupez l’exposition Internet immédiatement.

Dans tous les cas, ne mesurez pas votre exposition au seul score CVSS 8.0 : c’est la combinaison du PoC public et de la population non corrigible qui transforme cette faille en campagne potentielle.

Références

• NVD — CVE-2026-62911
• Microsoft — CVE-2026-62911 Exchange Server Elevation of Privilege
• BleepingComputer — Nearly 22,000 Microsoft Exchange servers vulnerable to hijack attacks
• Help Net Security — Microsoft Exchange CVE-2026-62911 critical authentication bypass flaw, 2 septembre 2026
• SentinelOne — CVE-2026-62911 vulnerability database entry