Dead.Letter : RCE critique non authentifiée dans Exim

Ce qui s'est passé

Le 22 mai 2026, BleepingComputer et The Hacker News ont révélé les détails d'une vulnérabilité critique affectant Exim, le serveur de messagerie open source qui équipe une grande partie de l'infrastructure mail mondiale. Identifiée sous le code CVE-2026-45185 et surnommée « Dead.Letter » par ses découvreurs, cette faille obtient un score CVSS de 9,8 sur 10, la plaçant directement dans la catégorie critique. Elle permet à un attaquant non authentifié d'exécuter du code arbitraire sur les serveurs cibles, sans nécessiter de compte ni d'accès préalable.

La vulnérabilité a été découverte et signalée le 1er mai 2026 par Federico Kirschbaum, responsable du Security Lab chez XBOW, une plateforme de test de sécurité autonome s'appuyant sur l'intelligence artificielle. Les mainteneurs d'Exim ont accusé réception le 5 mai et publié le correctif dans la version 4.99.3 avant la divulgation publique. La faille réside dans le module de traitement BDAT (Binary Data Transmission) d'Exim lorsque les connexions TLS sont gérées par la bibliothèque GnuTLS.

Techniquement, il s'agit d'un use-after-free (UAF) : Exim libère un tampon mémoire lors de la fermeture de la session TLS, mais continue d'utiliser des références de callbacks périmées pointant vers cette zone mémoire libérée. L'exploitation repose sur un scénario précis : un client envoie une alerte TLS close_notify avant la fin du transfert du corps du message, puis fait suivre un dernier octet en clair sur la même connexion TCP. Ce comportement amène Exim à écrire dans un buffer déjà libéré lors de la fermeture de session TLS, provoquant une corruption du tas (heap corruption).

Ce seul octet écrit hors limites suffit à corrompre les métadonnées internes de l'allocateur mémoire d'Exim. À partir de cette corruption initiale, un attaquant peut enchaîner d'autres primitives d'exploitation pour obtenir une exécution de code avec les privilèges du processus Exim. Sur la plupart des serveurs de production, cela se traduit par un accès en lecture aux boîtes mail hébergées, l'exécution de commandes système, et potentiellement un pivotement latéral vers d'autres services de l'infrastructure si les permissions le permettent.

Seules les versions 4.97 à 4.99.2 compilées avec l'option USE_GNUTLS=yes sont affectées. Les builds utilisant OpenSSL comme bibliothèque TLS ne sont pas touchées. L'exposition réelle est néanmoins massive : Exim est le serveur mail par défaut installé sur des millions de serveurs d'hébergement mutualisé depuis la fin des années 2010, et beaucoup n'ont jamais été migrés vers une autre solution. Selon les dernières données de recensement Shodan, Exim représente environ 56 % du marché des MTA (Mail Transfer Agent) exposés sur Internet.

Un élément marquant dans cette découverte est le rôle joué par l'IA dans la construction du proof-of-concept. Selon XBOW, la mise au point de l'exploit a constitué un défi de sept jours mené conjointement par XBOW Native — le système d'exploitation autonome de la plateforme — et un chercheur humain assisté d'un grand modèle de langage (LLM). Ce mode de travail hybride homme-machine a permis d'accélérer significativement le cycle de découverte et d'exploitation. Si des acteurs malveillants adoptent des méthodologies similaires, le délai entre divulgation et exploitation en conditions réelles pourrait se réduire à quelques heures.

Le blog officiel de XBOW, publié simultanément à la divulgation publique sous le titre « Dead.Letter — How XBOW found an unauthenticated RCE on Exim », détaille chaque étape technique de l'exploitation. Des analyses complémentaires ont été publiées par Palo Alto Networks Unit 42 et par Wiz. D'après le guide de réponse de Nine Lives ZeroTrust, les charges de travail Linux hébergées dans des clusters Kubernetes multi-locataires sont particulièrement exposées : une escalade réussie sur un pod exécutant Exim peut faciliter une évasion de conteneur et un mouvement latéral vers d'autres nœuds du cluster.

Le correctif est intégré dans Exim 4.99.3, disponible immédiatement via les gestionnaires de paquets des distributions majeures. Sur Ubuntu et Debian, la commande apt upgrade exim4 applique la mise à jour. Pour les distributions qui n'ont pas encore publié le paquet corrigé, la désactivation temporaire du support BDAT chunking dans la configuration Exim constitue une mesure de mitigation partielle. Les équipes disposant d'une infrastructure défensive peuvent également configurer des règles de détection ciblant les patterns de connexion TLS/BDAT anormaux décrits dans les indicateurs techniques publiés par Wiz et Palo Alto Networks Unit 42.

Pourquoi c'est important

La faille Dead.Letter illustre une tendance de fond qui s'est considérablement accélérée depuis 2025 : l'intégration des LLM et des systèmes d'exploitation autonomes dans les cycles de recherche offensive en sécurité. Pendant longtemps, la découverte et l'exploitation de vulnérabilités complexes comme les use-after-free restaient l'apanage de chercheurs très spécialisés, nécessitant des semaines de travail et une connaissance approfondie de l'allocateur mémoire cible. L'émergence de plateformes comme XBOW Native, qui combinent analyse statique et dynamique automatisée avec des LLM pour la génération de primitives d'exploitation, réduit ce délai à quelques jours.

Pour les équipes de défense, cette évolution impose de revoir en profondeur les délais de patching. La règle des 30 jours pour les vulnérabilités critiques n'est plus tenable lorsqu'un PoC fonctionnel peut être développé en une semaine par un acteur disposant d'outils d'IA offensifs. Sur des serveurs Exim exposés directement sur Internet, sans système de détection d'intrusion adapté, le délai entre publication et première exploitation malveillante peut se compter en heures. Le précédent de CVE-2023-42115 sur Exim avait déjà démontré la persistance du problème structurel : Exim est massivement déployé sur des infrastructures héritées dont les cycles de maintenance sont longs.

Les hébergeurs web mutualisés représentent le risque le plus élevé. Une compromission d'un serveur mail partagé expose simultanément l'ensemble des domaines hébergés sur ce serveur : accès aux communications internes, possibilité d'envoyer des spams ou des emails de phishing au nom des domaines hébergés, et collecte d'informations sensibles transitant par messagerie. Pour les sous-traitants d'entités essentielles qui hébergent des serveurs Exim, l'obligation de notification NIS2 en cas d'exploitation avérée s'applique avec des délais contraignants.

Du point de vue réglementaire, les entreprises opérant sous NIS2 ou DORA doivent considérer CVE-2026-45185 comme une vulnérabilité critique nécessitant une réponse sous 24 heures dans leur processus de gestion des vulnérabilités. L'absence de mise à jour rapide pourrait être retenue comme manquement à l'obligation de diligence dans le cadre d'un audit de conformité ou d'une procédure de notification d'incident au sens de NIS2.

Ce qu'il faut retenir

• CVE-2026-45185 est une RCE CVSS 9,8 non authentifiée dans Exim ; toute installation 4.97–4.99.2 compilée avec GnuTLS doit être mise à jour vers la version 4.99.3 immédiatement.
• Les builds OpenSSL ne sont pas affectées, mais l'identification de la bibliothèque TLS utilisée doit être vérifiée dans chaque environnement de production.
• L'IA a joué un rôle central dans la découverte et le développement du PoC, signalant une accélération du cycle d'exploitation qui impose des fenêtres de patching bien plus courtes.