Failles zero-day d'Exchange Server : ce qu'il faut corriger et vérifier

Deux vagues d'attaques ont visé les serveurs Exchange sur site avant même que les correctifs existent. Leur leçon tient en une règle : un serveur Exchange exposé doit être à jour, et l'on doit pouvoir le prouver.

Par la rédaction de Pixelabs · 12 octobre 2026

Une faille zero-day (ou « 0 day ») est une vulnérabilité exploitée par des attaquants avant que l'éditeur ait publié un correctif. Exchange Server sur site en a connu deux épisodes majeurs, en mars 2021 et en septembre 2022. Dans les deux cas, le guide des mises à jour de sécurité de Microsoft (MSRC) marque les vulnérabilités comme exploitées.

Cette page présente le risque, les versions touchées, les contrôles à faire et la remédiation publiée par Microsoft et commentée par le CERT-FR. Elle ne décrit aucune technique d'exploitation. Appliquez les mises à jour d'abord sur un serveur de test ou un membre de DAG isolé, après une sauvegarde.

Exchange 2016 et 2019 : un risque permanent

Le contexte a changé depuis ces attaques. Le support étendu d'Exchange 2016 et d'Exchange 2019 a pris fin le 14 octobre 2025. Seules les organisations inscrites au programme ESU (mises à jour de sécurité étendues) ont encore reçu des correctifs ; l'équipe Exchange a annoncé en août 2026 qu'il n'y aurait plus aucune mise à jour pour ces versions après octobre 2026, même avec un ESU. Pour continuer à recevoir les correctifs de sécurité, Microsoft oriente vers Exchange Server Subscription Edition (SE), décrite dans le guide de déploiement d'Exchange Server.

Mars 2021 : les vulnérabilités surnommées ProxyLogon

« ProxyLogon » est un surnom employé dans le secteur ; ni Microsoft dans ses fiches CVE ni le CERT-FR ne l'utilisent. Les fiches concernées :

Versions touchées : Exchange 2013, 2016 et 2019 selon le MSRC, et Exchange 2010 Service Pack 3 pour CVE-2021-26857. Le CERT-FR précise qu'Exchange Online n'est pas concerné. Les correctifs sont parus le 2 mars 2021 ; Microsoft a ensuite publié, du 8 au 16 mars, des correctifs pour d'anciennes mises à jour cumulatives (CU) qui n'étaient plus supportées, puis pour Exchange 2013 SP1.

L'alerte CERTFR-2021-ALE-004 du CERT-FR, mise à jour jusqu'au 16 juillet 2021, retient trois points :

• les vulnérabilités ayant été exploitées avant les correctifs, puis massivement, tous les serveurs Exchange doivent être considérés comme compromis ;
• l'outil d'atténuation publié par Microsoft le 15 mars 2021 ne protège que contre une exploitation future de CVE-2021-26855 et ne remplace ni le correctif ni la recherche de compromission ;
• le CERT-FR recommande de toujours maintenir les serveurs dans une version supportée, avec les dernières CU.

Septembre 2022 : les vulnérabilités surnommées ProxyNotShell

Même remarque : « ProxyNotShell » est un surnom du secteur, absent des alertes officielles.

Le MSRC a publié les deux fiches le 30 septembre 2022 ; les correctifs sont sortis le 8 novembre 2022. Les versions listées : Exchange 2013 CU23, Exchange 2016 CU22 et CU23, Exchange 2019 CU11 et CU12. Le MSRC précise que l'attaquant doit être authentifié.

L'alerte CERTFR-2022-ALE-008 indique que ces failles ont servi à des attaques ciblées, et que le CERT-FR avait connaissance d'incidents en France. En attendant les correctifs, elle recommandait d'appliquer les mesures d'atténuation de Microsoft, en particulier la désactivation de PowerShell à distance pour les utilisateurs non administrateurs, ainsi que la mise à jour du service EEMS.

Vérifier votre serveur

Le niveau de mise à jour

La question à poser n'est pas « suis-je vulnérable à telle CVE ? », mais « mon serveur a-t-il la dernière mise à jour de sécurité ? ». Microsoft recommande le script Health Checker pour lire le build installé et les correctifs détectés ; sans lui, cette commande documentée donne la version exacte d'ExSetup.exe, mise à jour de sécurité comprise :

Get-Command Exsetup.exe | ForEach-Object {$_.FileVersionInfo}

Comparez le numéro obtenu au tableau des builds de Microsoft. Pour savoir quelles CVE corrige une mise à jour, le guide des mises à jour de sécurité du MSRC permet de filtrer sur Exchange. La page Exchange troubleshooting détaille les autres contrôles de version et de services.

Les atténuations appliquées par EEMS

Le service d'atténuation d'urgence d'Exchange (Exchange Emergency Mitigation service, EEMS) s'installe automatiquement sur les serveurs Mailbox à partir des CU de septembre 2021 d'Exchange 2016 et 2019, et sur Exchange SE. Il n'est pas installé sur les serveurs Edge. Pour voir ce qu'il a appliqué :

Get-ExchangeServer | Format-List Name,MitigationsApplied,MitigationsBlocked

Microsoft présente chaque atténuation comme une solution provisoire, en attendant la mise à jour de sécurité. Sa table des atténuations publiées montre que le mécanisme sert toujours : M1 visait CVE-2022-41040, et M2 vise CVE-2026-42897, une vulnérabilité de 2026. Le paramètre MitigationsEnabled vaut $true par défaut ; le désactiver revient à renoncer à cette protection d'urgence.

La procédure de Microsoft, dans l'ordre

1. Inventorier les serveurs et leur niveau de mise à jour avec Health Checker.
2. Installer la dernière CU, puis la dernière mise à jour de sécurité ; l'assistant de mise à jour d'Exchange indique le chemin depuis votre CU actuelle.
3. Redémarrer et vérifier que tous les services Exchange ont démarré ; un service resté désactivé signale une installation interrompue.
4. Relancer Health Checker pour confirmer le nouveau build.
5. Retirer les atténuations EEMS devenues inutiles, selon la procédure de retour arrière documentée pour chacune.

Sur un DAG Exchange, basculez d'abord les bases actives vers un autre membre (switchover) avant de mettre un serveur à jour. Les serveurs de transport Edge, exposés directement à Internet et sans EEMS, doivent suivre le même rythme : voir le guide du serveur Edge. Les autres guides sont dans la rubrique Exchange Server.

Questions fréquentes