CVE-2026-62911 : pourquoi 85 % des serveurs Exchange sur site sont vulnérables et ce qui se cache techniquement derrière

Fin août 2026, le CERT-Bund du BSI a publié un chiffre qui interpelle : environ 85 % des serveurs Exchange sur site en Allemagne sont vulnérables à la faille CVE-2026-62911. Depuis le 14 août, l’autorité informe les opérateurs de réseaux concernés. L’élément déclencheur est la publication d’une preuve de concept permettant une prise de contrôle complète du système. Derrière le numéro CVE sobre se cache l’une des failles Exchange les plus intéressantes de ces dernières années : une attaque par relais via un point de terminaison que la plupart des administrateurs n’ont pas sur leur radar. Cet article explique le mécanisme, replace les chiffres du BSI dans leur contexte et décrit la marche à suivre concrète.

Pour ceux qui souhaitent uniquement situer la mise à jour de sécurité du 11 août 2026, l’aperçu des sept CVE, des builds et de la désactivation d’OWA Light se trouve dans l’article sur la mise à jour de sécurité d’août. Il est ici question de cette unique faille critique en détail.

Ce qu’est réellement CVE-2026-62911

Microsoft classe CVE-2026-62911 comme une Elevation of Privilege avec un score CVSS de 8.0 et la considère comme la seule vulnérabilité Critical du Patch Tuesday d’août. La catégorie CWE fournit une description plus précise : CWE-294, « Authentication Bypass by Capture-Replay ». L’attaquant ne contourne pas l’authentification en devinant un mot de passe, mais en interceptant une authentification valide d’un autre compte et en la réutilisant contre un point de terminaison cible. En pratique, il s’agit d’une attaque classique de relais NTLM.

La faille a été découverte par Orange Tsai de l’équipe de recherche DEVCORE. Il l’a démontrée lors du concours Pwn2Own Berlin 2026, comme élément d’une chaîne de trois vulnérabilités qui permettaient ensemble l’exécution de code à distance avec des droits SYSTEM sur le serveur Exchange. Cette combinaison explique l’apparente contradiction de nombreux rapports : prise isolément, CVE-2026-62911 est une élévation de privilèges qui suppose un contexte déjà authentifié. Associée à une technique de coercition qui force d’abord l’authentification, elle devient une attaque non authentifiée depuis le réseau. C’est précisément cette combinaison qu’utilise la preuve de concept.

Le cœur du problème : MRSProxy sans Channel Binding

Le point de terminaison vulnérable s’appelle MRSProxy, abréviation de Mailbox Replication Service Proxy. Exchange le fournit afin de pouvoir déplacer des boîtes aux lettres entre serveurs et, dans des environnements hybrides, entre les installations sur site et Exchange Online. MRSProxy accepte l’authentification Negotiate, mais ne vérifie pas les Channel Bindings. C’est précisément cette vérification qui est au cœur du problème.

Le Channel Binding lie l’authentification au canal TLS sous-jacent. En simplifiant, le client inscrit une empreinte cryptographique de la connexion TLS dans les données d’authentification. Le serveur vérifie si cette empreinte correspond à la connexion par laquelle les données arrivent. Si ce n’est pas le cas, l’authentification a transité par un autre canal que celui qu’elle prétend utiliser, et le serveur la refuse. Ce procédé constitue la base technique d’Extended Protection for Authentication. En l’absence de vérification, une authentification interceptée ailleurs peut être transmise au point de terminaison, puis l’attaquant est traité comme le compte d’origine.

Le point décisif pour l’exploitation : cette faille existait alors même qu’Extended Protection est activée par défaut depuis longtemps dans les versions actuelles d’Exchange. Le point de terminaison MRSProxy constituait une exception dans la protection : il n’imposait pas le Channel Binding appliqué par les autres points de terminaison. La mise à jour de sécurité comble précisément cette lacune en ajoutant la vérification dans MRSProxy. Il n’existe donc pas de solution de contournement via Exchange Emergency Mitigation : la mise à jour d’août est le correctif.

Déroulement de l’attaque

La preuve de concept publiée associe quatre éléments. Chacun est connu individuellement ; c’est leur combinaison qui fait l’attaque.

Lors de la première étape, l’attaquant amène le serveur Exchange à s’authentifier de lui-même. Pour cela, il utilise la technique de coercition PetitPotam via l’interface RPC d’impression MS-EFSR : un appel préparé incite le serveur à se connecter auprès de l’attaquant avec son propre compte machine. Ce compte possède des droits élevés sur le système Exchange. Lors de la deuxième étape, l’attaquant transmet immédiatement cette connexion au point de terminaison MRSProxy au lieu d’y répondre lui-même. Comme MRSProxy ne vérifie pas le Channel Binding (troisième étape), Exchange accepte la connexion transmise bien qu’elle soit arrivée par un tout autre canal. L’attaquant agit alors avec les droits du compte serveur et peut, lors de la quatrième étape, écrire un fichier, généralement une webshell ASPX, puis exécuter du code arbitraire en tant que SYSTEM.

Le résultat est une prise de contrôle complète du serveur. Pour les victimes, cela signifie l’accès à toutes les boîtes aux lettres : lecture et envoi d’e-mails, téléchargement de pièces jointes, indépendamment de chaque utilisateur. Un serveur Exchange n’est alors plus un système de messagerie isolé, mais un pied dans la porte de l’Active Directory situé derrière.

Versions concernées et correctifs

Toutes les versions sur site encore prises en charge sont concernées. La mise à jour de sécurité du 11 août 2026 porte les serveurs aux builds suivants :

C’est là que réside la véritable cause du taux élevé de vulnérabilité. Exchange Server 2016 et 2019 ne bénéficient plus du support standard depuis octobre 2025. Leurs mises à jour de sécurité de mai à octobre 2026 ne sont accessibles qu’aux organisations inscrites au programme payant Extended Security Updates (Period 2). Selon le BSI, seuls neuf serveurs Exchange 2016/2019 en Allemagne ont reçu un correctif par ce programme. La grande majorité reste donc tout simplement non corrigée.

Exchange Online n’est pas concerné par la faille ; Microsoft a déjà sécurisé la partie cloud. Dans les environnements hybrides, la mise à jour doit néanmoins être installée sur chaque serveur sur site, y compris les serveurs de gestion uniquement et les machines sur lesquelles seuls les Exchange Management Tools sont installés.

Lire correctement les chiffres du BSI

L’enquête provient du CERT-Bund, qui détermine l’état de mise à jour des serveurs Exchange accessibles depuis Internet à l’aide de ses propres analyses et de données de partenaires. Trois chiffres sont essentiels, et ils sont liés.

Premièrement : fin octobre 2025, 92 % des quelque 33’000 serveurs Exchange sur site en Allemagne exécutaient une version qui n’était plus prise en charge. C’est la situation structurelle de départ. Deuxièmement : environ 85 % de ces serveurs sont vulnérables à CVE-2026-62911, car il leur manque le correctif d’août. Troisièmement : seuls neuf serveurs ont été corrigés de manière vérifiable via le programme ESU Period 2. Ces chiffres décrivent la même situation sous deux angles. Une grande partie des serveurs n’est pas non corrigée parce qu’une mise à jour a été oubliée, mais parce qu’il n’existe tout simplement plus de mise à jour standard pour la version utilisée. Le véritable retard n’est pas une lacune de correctif, mais une lacune de migration.

Il n’existe pas d’enquête comparable couvrant l’ensemble de la Suisse. La situation de départ est toutefois structurellement similaire, car Exchange 2016 et 2019 y sont également très répandus et ne sont plus pris en charge depuis octobre 2025. Le NCSC (Office fédéral de la cybersécurité) recommande systématiquement d’installer sans délai les mises à jour en cas de vulnérabilités critiques activement exploitées. Les organisations suisses qui exploitent Exchange 2016 ou 2019 sur site sont confrontées à la même décision que les opérateurs allemands : corriger via ESU comme solution transitoire, puis migrer.

Ce qu’il faut faire maintenant

Les mesures sont claires et il est judicieux de les appliquer dans cet ordre.

Installez la mise à jour de sécurité d’août sur tous les serveurs Exchange. Pour Exchange SE, il s’agit d’une mise à jour publique standard. Pour Exchange 2016 et 2019, elle nécessite une inscription au programme ESU Period 2 ; sans cette inscription, vous ne recevrez pas le correctif. Il n’existe aucune procédure de contournement via Exchange Emergency Mitigation pour cette faille.

Vérifiez qu’Extended Protection est actif et correctement configuré sur tous les points de terminaison. Il s’agit de la protection structurelle durable contre les attaques par relais de ce type, et elle les bloque là où le Channel Binding s’applique. La mise à jour et Extended Protection ne se remplacent pas : le correctif comble la faille concrète de MRSProxy, tandis qu’Extended Protection renforce l’authentification dans son ensemble. Les deux vont de pair.

Limitez l’accès depuis Internet aux services Exchange basés sur le web. Un serveur dont les points de terminaison de gestion et de réplication ne sont pas accessibles depuis Internet, par exemple parce qu’ils ne sont disponibles que via VPN, prive cette attaque de son fondement. Cela ne remplace pas la mise à jour, mais réduit sensiblement la surface d’attaque.

Et la véritable conséquence à tirer des chiffres du BSI : planifiez la migration hors d’Exchange 2016/2019. Le programme ESU est un pont jusqu’en octobre 2026, pas un état permanent. Les organisations qui appliquent aujourd’hui des correctifs via le programme ESU achètent du temps pour une transition ordonnée vers Exchange SE ou Exchange Online, rien de plus. Chaque mois supplémentaire sur une version qui n’est plus prise en charge prolonge la période durant laquelle la prochaine faille surviendra sans correctif disponible.