Microsoft Exchange CVE-2026-42897 : le zero-day OWA qui n'a toujours pas de patch — plan d'action urgent pour les RSSI francais

— Ce qui s'est passe : chronologie d'un zero-day sans correctif

Mercredi 14 mai 2026, Microsoft a publie un avis de securite confirmant l'existence et l'exploitation active de CVE-2026-42897, une vulnerabilite de type Cross-Site Scripting (XSS) dans le composant Outlook Web Access (OWA) de Microsoft Exchange Server. Le mecanisme est a la fois simple et devastateur : un attaquant envoie un e-mail specialement concu a la victime. Lorsque celle-ci ouvre cet e-mail dans OWA via son navigateur, du code JavaScript arbitraire s'execute dans le contexte de sa session authentifiee — sans aucune interaction supplementaire requise de la part de l'utilisateur au-dela de l'ouverture du message.

Ce n'est pas un simple XSS « reflected » qui necesiterait de cliquer sur un lien malveillant. C'est un stored XSS declenche par le rendu HTML du corps de l'e-mail dans OWA. Le moteur de rendu d'Exchange Server echoue a neutraliser certaines constructions HTML/CSS imbriquees qui permettent l'injection de balises <script> via un encodage specifique du contenu MIME. Le score CVSS de 8.1 reflète l'impact eleve en termes de confidentialite et d'integrite, tempere uniquement par la necessite que la victime utilise OWA (et non le client lourd Outlook).

Le 15 mai, soit 24 heures apres la divulgation, la CISA a ajoute CVE-2026-42897 a son catalogue Known Exploited Vulnerabilities (KEV), fixant une deadline de remediation au 29 mai 2026 pour les agences federales americaines. Le meme jour, le NHS England a emis une alerte cyber specifique pour le secteur sante, et Microsoft a publie un guide de mitigation detaille sur Tech Community. Au 21 mai 2026, aucun correctif permanent n'existe.

— Pourquoi les entreprises francaises sont particulierement exposees

La France compte un nombre significatif d'organisations qui maintiennent des serveurs Exchange on-premises. Selon les donnees Shodan analysees par plusieurs chercheurs independants dans les jours suivant la divulgation, plus de 12 000 serveurs Exchange sont directement accessibles depuis Internet en France, dont une proportion non negligeable expose OWA sans restriction d'acces IP. Les secteurs les plus representes : sante (CHU, cliniques privees, laboratoires), collectivites territoriales, PME industrielles, et cabinets d'avocats — des organisations qui n'ont souvent ni les competences internes ni le budget pour une migration cloud rapide.

Le contexte reglementaire ajoute une couche de complexite. De nombreuses organisations du secteur sante maintiennent Exchange on-premises pour des raisons de conformite HDS (Hebergement de Donnees de Sante). Certaines administrations ne migrent pas vers Microsoft 365 en raison de la doctrine « cloud de confiance » et des recommandations de l'ANSSI sur la souverainete des donnees. Ces organisations se retrouvent prises en etau : elles ne peuvent pas migrer vers Exchange Online (non affecte), elles ne disposent pas de patch, et elles doivent appliquer des mitigations temporaires sur des infrastructures souvent gerees par des equipes IT generalistes.

L'exploitation observee dans la nature cible precisement ce profil d'organisations. Security Affairs a rapporte que les premieres campagnes d'exploitation identifiees ciblaient des organisations du secteur sante et du secteur public en Europe, avec des e-mails rediges en francais, en allemand et en italien — un signe clair que les attaquants connaissent le profil des cibles Exchange on-premises en Europe.

— Anatomie de l'attaque : du mail crafté a l'execution de code dans le navigateur

Comprendre la chaine d'exploitation est essentiel pour evaluer les mitigations. Voici le flux d'attaque complet de CVE-2026-42897, de l'envoi du mail malveillant a l'exfiltration de donnees :

Le point cle pour les RSSI : la surface d'attaque est chaque utilisateur qui accede a sa messagerie via OWA dans un navigateur. Les utilisateurs du client lourd Outlook (desktop) ne sont pas affectes car le moteur de rendu HTML est different. Les utilisateurs d'Outlook Mobile ne sont pas affectes non plus. Seul le composant OWA web est vulnérable. C'est une information essentielle pour dimensionner votre plan de mitigation : si aucun de vos utilisateurs n'utilise OWA, votre exposition est theoriquement nulle — mais verifiez que OWA n'est pas tout de meme accessible depuis Internet, car un attaquant pourrait tenter de rediriger un utilisateur vers l'interface OWA.

— Quelles versions d'Exchange sont vulnerables — et lesquelles ne le sont pas

La confusion est frequente entre les differentes editions et modes de deploiement d'Exchange. Voici un schema synthetique pour clarifier la situation :

Le cas le plus delicat est celui des entreprises en mode hybride. Beaucoup d'organisations ont migre leurs boites aux lettres vers Exchange Online mais conservent un serveur Exchange on-premises pour la gestion des attributs Active Directory ou pour des boites aux lettres specifiques (salles de conference, comptes de service). Si OWA est active sur ce serveur residuel — et c'est le cas par defaut — vous etes potentiellement expose, meme si 95 % de vos utilisateurs sont sur Microsoft 365.

— Mitigations disponibles : comparatif des options

En l'absence de patch permanent, Microsoft a publie plusieurs mitigations temporaires. Voici un comparatif de leur efficacite, de leur complexite de deploiement et de leur impact sur les utilisateurs :

Notre recommandation pour une entreprise francaise avec une utilisation active d'OWA : combiner la restriction IP (VPN obligatoire) avec les regles WAF et la CSP restrictive. Cette approche en profondeur couvre les variantes connues et inconnues tout en maintenant l'acces pour les utilisateurs qui en ont un besoin metier justifie. Pour les organisations qui n'utilisent pas OWA au quotidien, la desactivation complete est la solution la plus sure et la plus simple.

— Plan d'action detaille pour les RSSI — mitigations immédiates

Etape 1 : Inventaire de vos serveurs Exchange on-premises (1 heure)

Avant toute chose, identifiez l'ensemble de vos serveurs Exchange on-premises. Utilisez Get-ExchangeServer | Select-Object Name, Edition, AdminDisplayVersion, ServerRole dans l'Exchange Management Shell pour lister toutes les instances. N'oubliez pas les serveurs « fantomes » : serveurs de test, serveurs hybrides residuels, anciens serveurs non decommissionnes. Verifiez si OWA est active sur chacun avec Get-OwaVirtualDirectory | Select-Object Server, InternalUrl, ExternalUrl. Sur les six clients que j'ai audites cette semaine, deux avaient des serveurs Exchange que personne ne considerait comme « en production ».

Etape 2 : Evaluer l'exposition OWA depuis Internet (30 minutes)

Testez depuis une connexion externe si vos URLs OWA sont accessibles : curl -sI https://mail.votredomaine.fr/owa | head -20. Verifiez aussi les variantes : /owa, /OWA, /exchange, /Autodiscover. Si OWA repond avec un code 200 ou 302 vers une page de login, votre serveur est expose. Consultez egalement Shodan et Censys pour identifier des serveurs Exchange que vous auriez oublies. Pour les organisations sensibles, cette demarche est complementaire de l'approche que nous detaillons dans notre article sur comment securiser ses API — la logique de reduction de la surface d'attaque est la meme.

Etape 3 : Appliquer les mitigations Microsoft (2 heures)

Microsoft recommande trois mitigations immediates. Premiere mitigation : desactiver les scripts inline dans OWA via une politique Content Security Policy. Ajoutez le header Content-Security-Policy: script-src 'self' sur le repertoire virtuel OWA dans IIS. Attention : cela peut casser certaines fonctionnalites OWA (recherche avancee, integration de calendrier, certains add-ins). Testez sur un serveur de pre-production avant de deployer. Deuxieme mitigation : forcer le header X-Content-Type-Options: nosniff si ce n'est pas deja le cas — cela empeche le navigateur d'interpreter du contenu MIME de maniere inattendue. Troisieme mitigation : restreindre l'acces OWA aux plages IP internes ou aux connexions VPN, en utilisant les URL Rewrite rules dans IIS ou un reverse proxy en amont.

Etape 4 : Deployer des regles WAF (1 heure)

Si vous utilisez un WAF en amont de votre serveur Exchange (et vous devriez), deployez des regles bloquant les payloads XSS connus dans les requetes OWA. Les signatures doivent cibler les sequences d'encodage HTML imbriquees dans les requetes POST vers /owa/ et les reponses contenant des balises <script> dans le corps des e-mails rendus. Les principaux editeurs de WAF (Cloudflare, AWS WAF, Azure Front Door, F5, Imperva) ont publie des jeux de regles specifiques a CVE-2026-42897 entre le 15 et le 17 mai.

— Comment detecter si vous avez deja ete compromis

Etant donne que CVE-2026-42897 est exploitee activement depuis au moins le 14 mai, la question n'est plus seulement « suis-je vulnerable ? » mais aussi « ai-je deja ete compromis ? ». Voici les indicateurs a verifier en priorite.

Logs IIS d'OWA : recherchez dans les logs IIS du repertoire virtuel OWA les requetes POST anormalement longues (corps > 50 Ko) contenant des sequences d'encodage HTML multiples. La commande PowerShell Select-String -Path "C:\inetpub\logs\LogFiles\W3SVC1\*.log" -Pattern "POST /owa.*\d{5,}" | Select-Object -First 100 permet un premier tri rapide. Regles de transfert : l'un des objectifs courants apres exploitation est la creation de regles de transfert automatique. Verifiez avec Get-InboxRule -Mailbox * | Where-Object {$_.ForwardTo -or $_.ForwardAsAttachmentTo -or $_.RedirectTo} | Select-Object MailboxOwnerId, Name, ForwardTo, RedirectTo. Sessions OWA inhabituelles : consultez les logs d'audit Exchange pour identifier des connexions OWA depuis des IP ou des user agents inhabituels.

Si vous identifiez un indicateur de compromission, le reflexe est le meme que pour toute vulnerabilite critique : isoler le serveur, preserver les preuves (snapshot VM, export des logs IIS des 30 derniers jours), notifier votre CERT et, si vous etes soumis a NIS2, notifier l'ANSSI dans les 24 heures. Pour approfondir les techniques de detection et de reponse, notre article sur les zero-days Microsoft Defender exploites en avril 2026 decrit une methodologie similaire applicable ici.

— Arbre de decision : quelle strategie de remediation pour votre organisation

Chaque organisation a un contexte different. Voici l'arbre de decision que j'utilise avec mes clients pour determiner la strategie de remediation la plus adaptee :

— Ce que ca signifie pour vous

CVE-2026-42897 cristallise un probleme structurel de la cybersecurite des entreprises francaises en 2026 : la dependance persistante a des infrastructures on-premises pour la messagerie. Exchange on-premises n'est pas en soi une mauvaise technologie, mais c'est devenu un choix qui exige des competences securite specialisees, une veille CVE quotidienne et une capacite de reaction en heures, pas en jours. Tres peu de PME et d'ETI francaises disposent de ces ressources en interne.

La question strategique que chaque RSSI devrait poser a sa direction apres cet incident est la suivante : quel est le cout total de maintien d'Exchange on-premises — patches d'urgence, mitigations temporaires, investigations forensiques, risque residuel — compare au cout d'une migration vers Exchange Online ? Dans la majorite des cas que j'observe, le cout de maintien a depasse le cout de migration depuis deux ou trois ans, mais l'inertie organisationnelle et les contraintes reglementaires perçues retardent la decision.

Pour les organisations qui ne peuvent pas migrer (contraintes HDS, souverainete, reglementaires), la lecon est differente mais tout aussi importante : un serveur Exchange on-premises expose sur Internet en 2026 doit etre protege par un WAF, un reverse proxy avec restriction IP, un monitoring renforce des logs IIS et une capacite de patching sous 24 heures. C'est le minimum. Si votre organisation n'est pas en mesure de garantir ce niveau de protection, elle n'est pas en mesure d'operer Exchange on-premises de maniere securisee.

— Predictions : ce qui va se passer dans les prochaines semaines

Semaine du 26 mai : Microsoft devrait publier le patch out-of-band pour Exchange Server 2019 et Subscription Edition. Exchange 2016 etant hors support etendu depuis octobre 2025, un patch est incertain — Microsoft pourrait publier une exception, comme ils l'ont fait pour certaines vulnerabilites critiques post-EOS, mais ce n'est pas garanti. Les organisations encore sur Exchange 2016 doivent considerer cela comme un signal definitif de migration.

Fin mai — debut juin : les campagnes d'exploitation vont s'intensifier. L'ajout au catalogue CISA KEV et la couverture mediatique attirent l'attention des groupes opportunistes qui scannent massivement les serveurs Exchange exposes. C'est un schema classique observe apres ProxyLogon (2021) et ProxyShell (2021) : la fenetre entre la divulgation et le patching generalise est exploitee de maniere industrielle. Les serveurs Exchange non mitigues au 29 mai seront des cibles de masse.

Ete 2026 : nous observerons probablement les premieres consequences en termes de fuites de donnees et de fraudes BEC liees a cette vulnerabilite. L'experience de ProxyLogon montre que les compromissions silencieuses (regles de transfert, persistence) ne sont souvent decouvertes que plusieurs semaines apres l'exploitation initiale. Les organisations qui se contentent d'appliquer les mitigations sans mener d'investigation s'exposent a des incidents differees.

— Questions frequentes